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 Карактеристики на програмата за брзо испраќање ДР 29

9.4.2 OpenADR Карактеристики за капацитети за наддавање програми 31

9.5 Програма за време на употреба (TOU) за резиденцијално електрично возило (EV) 33

9.5.1 Програмски карактеристики на станбени EV TOU 33

9.5.2 OpenADR Карактеристики за станбени EV TOU програми 33

9.6 Програма за цени во реално време на јавна станица за електрично возило (EV) 34

9.6.1 Програмски карактеристики на јавна станица EV RTP 34

9.6.2 OpenADR Карактеристики за јавните станици EV RTP програми 34

9.7 Програма за дистрибуирани енергетски ресурси (DER) DR 35

9.7.1 Програмски карактеристики на дистрибуирани енергетски ресурси (DER) 35

9.7.2 OpenADR карактеристики за дистрибуирани енергетски ресурси (DER) 35

Анекс А – СampШаблони за податоци и носивост 36

А.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 Sample Event Payload – Typical B Profile Користете го случајот 37

А.2 Програма за наддавање за капацитет (CBP) 39

A.2.1 CBP Сценарио 1 – Случај за едноставна употреба, A или B Profile 39

A.2.2 CBP Сценарио 2 – Типичен случај на употреба, Б проfile 39

A.2.3 CBP Сценарио 3 – Случај на сложена употреба 40

A.2.4 CBP Sample Event Payload – Typical B Profile Користете го случајот 40

A.3 Програма за станбен термостат 42

А.3.1 Резиденцијален термостат Сценарио 1 – Едноставна футрола за употреба, A или B Profile 42

A.3.2 Резиденцијален термостат Сценарио 2 – типичен случај на употреба, B profile 42

А.3.3 Резиденцијален термостат Сценарио 3 – Случај за сложена употреба 43

А.3.4 Станбен термостат Сample Event Payload – Typical B Profile Користете го случајот 43

А.4 Брзо DR испраќање 45

A.4.1 Брзо DR Сценарио 1 – Случај за едноставна употреба, A или B Profile 45

A.4.2 Брзо DR Сценарио 2 – Типичен случај на употреба, B profile 45

A.4.3 Брзо DR Сценарио 3 – Случај за сложена употреба 46

А.4.4 Брз ДР Сample Event Payload – Typical B Profile Користете го случајот 46

А.4.5 Брз ДР СampИзвештај за оптоварување со метаподатоци – Типичен B Profile Користете го случајот 48

А.4.6 Брз ДР Сample Пријавете барање за носивост – Типично B Profile Користете го случајот 48

А.4.7 Брз ДР СampПријавете оптоварување со податоци – Типично B Profile Користете го случајот 49

A.5 Програма за време на употреба (TOU) за резиденцијално електрично возило (EV) 49

A.5.1 Резиденцијално EV Сценарио 1 – Случај за едноставна употреба, A или B Profile 49

A.5.2 Резиденцијално EV Сценарио 2 – Случај за типична употреба, B profile 50

А.5.3 Станбена ЕВ Сample Event Payload – Typical B Profile Користете го случајот 50

A.6 Програма за цени во реално време за електрично возило (EV) за јавна станица 53

A.6.1 Јавна станица EV Сценарио 1 – Случај за типична употреба, B profile 53

А.6.2 Јавна станица ЕВ Сample Event Payload – Typical B Profile Користете го случајот 53

A.7 Дистрибуирани енергетски ресурси (DER) DR Програма 54

Анекс Б – Дефиниции за сервис и носивост 55

Б.1 Отворениот ADR ги поддржува следните услуги: 55

Анекс В – Дефиниции за сервис и носивост 56

В.1 Товари на EiEvent 56

В.2 Оптоварувања на EiReport 56

В.3 EiOpt носивост 56

В.4 Товари на EiRegisterParty 57

В.5 Оптоварувања на OadrPoll 57

Анекс Г – Речник на елементи на оптоварување на шемата 58

Прилог Е Поимник на набројани вредности 65

Е.1 Статус на настан 65

Д.2 ставка Единици 65

E.3 oadrКвалитет на податоци 65

E.4 oadrResponseRequired 66

E.5 optReason 66

E.6 oadrTransportName 66

E.7 OptType 66

Д.8 читање Тип 66

E.9 извештајИме 67

Д.10 извештај Тип 67

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

E.12 Име на сигналот 68

Е.13 сигнал Тип 69

Анекс F – OpenADR A и B Profile Разлики 70

Анекс G – OpenADR безбедносни сертификати 71

Вовед

Целната публика за овој водич е комуналните претпријатија кои планираат да распоредат програми за одговор на побарувачката (DR) кои користат OpenADR 2.0 за комуникација со пораки поврзани со настанот DR помеѓу претпријатието и долните ентитети, и производителите на опрема што ја олеснуваат таа комуникација. Се претпоставува дека читателот има основно концептуално разбирање и за одговорот на побарувачката и за OpenADR 2.0 (од оваа точка натаму едноставно се нарекува OpenADR).

Професионалниот OpenADRfile спецификациите јасно го дефинираат очекуваното однесување кога се разменуваат информации поврзани со DR настан, но сепак има доволно можности во OpenADR дека распоредувањето на сервери (VTN) во алатката и клиенти (VEN) на долните локации не е искуство со plug-n-play. Карактеристиките на OpenADR како што се сигналите за настани, форматите на извештаи и таргетирањето мора да се специфицираат врз основа на DR програма по програма.

Не постои такво нешто како стандардизирана програма за ДР. Секој дизајн на DR програма има тенденција да биде уникатен, одговарајќи на структурните и регулаторните барања на географскиот регион во кој е распореден. За секоја програма за ДР постојат бројни можни сценарија за распоредување кои вклучуваат различни актери.

Варијабилноста во дизајните на DR програмите, сценаријата за распоредување и карактеристиките на OpenADR се инхибитор за проширеното распоредување на DR и употребата на OpenADR. Оваа варијабилност во најголем дел е одраз на фрагментираната и сложена природа на паметната мрежа.

Комуналните услуги треба прampлес од типични DR програми за да можат да се користат како модели за нивните сопствени имплементации на DR програми. Производителите на опрема треба да ги разберат типичните модели на користење на DR Програмата за да можат да ја потврдат интероперабилноста како дел од процесот на развој, наместо на специфична основа за распоредување на програмата DR. Целта на овој водич е да ги постигне двете овие цели на следниов начин:

• Дефинирајте мал сет на стандардни шаблони за DR програма моделирани според заедничките карактеристики на најпопуларните DR програми имплементирани до денес
• Дефинирајте мал сет на сценарија за распоредување моделирани по распоредувања во реалниот свет, со актери и улоги јасно идентификувани
• Дефинирајте препораки за најдобри практики за карактеристиките на OpenADR специфични за секој од шаблоните на Програмата DR
• Обезбедете стебло на одлуки што може да го користат комуналните услуги за да ги идентификуваат корисните шаблони на програмата DR и сценаријата за распоредување врз основа на нивните деловни потреби

Акцентот во овој водич ќе биде ставен на нештата да бидат едноставни со обезбедување на мал сет на јасни препораки кои ќе се однесуваат на поголемиот дел од деталите потребни за распоредување на типична програма за DR и ќе овозможат тестирање на интероперабилност на опремата распоредена во програмите користејќи ги препораките во оваа водич.

Референци

• OpenADR Profile Спецификација и шема – www.openadr.org

Поими и дефиниции

Во овој документ се користат следните термини и дефиниции.

• Одговор на побарувачката: Механизам за управување со побарувачката за оптоварување на клиентите како одговор на условите за снабдување, како што се цените или сигналите за достапност
• Агрегаторска партија – Ова е партија која собира повеќе ресурси заедно и ги презентира на страната на програмата DR како единствен ресурс во нивните DR програми.
• Агрегатор посредничка инфраструктура – Ова е инфраструктура, одвоена од Инфраструктурата на страната на побарувачката, која се користи од страната посредник агрегатор за да комуницира и со ресурсите и со ентитетите од страната на мрежата
• Договор: Договорен договор помеѓу страните кои играат улога во програмата за ДР, во кој се наведени одговорностите и компензацијата
• Средство – Вид на ресурси што претставува специфична колекција на физички оптоварувања. Ресурсите може да се состојат од средства, а средството може да биде ресурс, но средствата не може дополнително да се разложат на повеќе средства или ресурси.
• Поврзани: Обезбедете програмска асоцијација помеѓу два ентитета, преку конфигурација на уред за база на податоци. На пример, поврзани ресурси со VEN
• Основни линии: Пресметаната или измерената потрошувачка на енергија (побарувачката) од страна на парче опрема или локација пред настанот како што е утврдено преку истражувања, инспекции и/или мерење на локацијата.
• BMS – Ова е Системот за управување со згради што може да се користи за контрола на ресурсите. Ова понекогаш се нарекува систем за управување со енергија.
• Составен ресурс – Ова е посебен вид на ресурси што е збир на повеќе физички средства од кои секој има свои средства за контрола на оптоварувањето.
• Стимулација на клиентите: Поттик што му се дава на сопственикот/агрегаторот на ресурсите од страната на побарувачката за учество во програма за ДР.
• Инфраструктура на страната на побарувачката – Ова е инфраструктурата во која се сместени ресурсите кои се запишани во програмите за ДР
• ДР Логика: Алгоритми или логика кои ги претвораат DR сигналите во активна контрола на оптоварувањето. Забележете дека DR Logic може да се имплементира на многу различни локации и во некои случаи да се дистрибуира меѓу повеќе подсистеми.
• ДР програма партија – ова е субјектот кој е одговорен за мрежната инфраструктура и дополнително за управување со DR програмите што се користат за ублажување на проблемите со мрежата. Ова е обично Utility или ISO.
• Запишан: Сопственикот/агрегаторот на ресурсите од страната на побарувачката избира да учествува во програма за ДР и може да обезбеди информации за специфичните ресурси кои можат да бидат насочени за настани за ДР
• Активен период на настанот: The е периодот во времето во кое се врши промена на оптоварувањето проfile се бара како дел од DR настан
• Ограничувања на настанот: Временските рамки во кои клиентот може да очекува да добие настани и поврзани ограничувања како што се нема настани за време на викенди или последователни денови
• Денови на настанот: Ден кога се случува настан за ДР. Повеќето програми имаат ограничувања во однос на бројот на денови на настани што се дозволени во даден календарски период
• Опис на настанот: Дел од објектот на настанот OpenADR кој опишува метаподатоци за настанот, како што се името на програмата и приоритетот на настанот
• Времетраење на настанот: Должината на настанот. Повеќето програми дефинираат ограничувања за должината на настанот, како и часовите од денот во кои настанот може да се случи
• Сигнали за настани: Активните информации содржани во настан, како што се цените на електричната енергија или специфичните нивоа на оптоварување бараа што обично предизвикуваат некое претходно програмирано однесување за намалување на товарот од страна на примачот на настанот. Дефиницијата на програмата DR треба да ги специфицира типовите на сигнали за настани што се користат
• Таргетирање на настани: Ресурсите за намалување на оптоварувањето кои се наменети за примачот за настанот DR. Може да биде географска област, одредена класа на уреди, идентификатор на група, ID на ресурс или друг идентификатор. Дефиницијата на програмата за ДР треба да специфицира како конкретните ресурси ќе бидат насочени.
• Настани: Настанот е известување од претпријатието за барање странични ресурси кои бараат отфрлање на оптоварувањето почнувајќи во одредено време, во одредено времетраење и може да вклучува информации за таргетирање кои означуваат специфични ресурси кои треба да учествуваат во настанот
• Посредничка инфраструктура на олеснувач – Ова е инфраструктура, одвоена од Инфраструктурата на страната на побарувачката, која ја користи Посредничката страна на олеснувачот за интеракција и со ресурсите и со субјектите од страната на мрежата.
• Олеснувач: Трета страна која управува со дел или со целото извршување на програмата DR во име на алатката
• Мрежна инфраструктура – Ова е инфраструктура која е во сопственост или управувана од страна на програмските страни на ДР. Оваа инфраструктура вклучува имплементација на OpenADR VTN што се користи за испраќање DR сигнали до ресурси запишани во DR програмите
• Посредничка страна – Ова е партија која вообичаено работи во име на Страната со ресурси за да го олесни нивното учество во програмите за ДР.
• Контрола на оптоварување – ова е инфраструктура поврзана со ресурс кој е одговорен за всушност контролирање на ресурсот и производство на специфично оптоварување проfile.
• Вчитај Проfile Цел: Оваа мотивација зад развивање програма за ДР и издавање настани. Како што е желбата да се избричат ​​врвните оптоварувања.
• Известување: временски период пред почетокот на настанот каде што сопственикот на ресурси од страната на побарувачката е известен за настан што чека
• Одлучете се за однесување: Очекуваниот одговор од сопственикот на ресурсите од страната на побарувачката по приемот на настанот. Овој одговор може да биде во форма на назначување OptIn или OptOut дали ресурсот ќе учествува на настанот или не
• Одлучете ги одговорите: Дали одредена програма треба да бара одговор од ресурсите на страната на побарувачката како одговор на настанот, и кои се тие одговори обично.
• Одлучете ги услугите: Распоредите доставени преку OpenADR за да се наведат привремени промени во достапноста на ресурсите за учество во настани.
• Предуслов: Критериуми што мора да се исполнат за да може сопственикот на ресурси од страна на побарувачката да се запише во програма за ДР. Ова може да вклучува достапност на интервален состанок или одреден минимален капацитет за оптоварување
• Примарни драјвери: Примарната мотивација од делот на комуналното претпријатие за креирање на програмата ДР и издавање настани. Како што се „Намалување на врвната побарувачка и адекватност на ресурсите“
• Програми – Ова се DR програмите во кои се запишани ресурсите.
• Опис на програмата: Наративен опис за тоа како функционира програмата. Дел од шаблоните на Програмата DR дефинирани во овој документ
• Временска рамка на програмата: Времето од годината или годишните времиња со програма за ДР обично се активни
• Стапка дизајн: Специфичните модификации на структурата на стапката или стимулациите што се плаќаат за да се мотивираат сопствениците на ресурси од страната на побарувачката да учествуваат во програмата
• Услуги за регистрација: Услуга што се користи од протоколот OpenADR за да се воспостави основна интероперабилност помеѓу VTN и VEN и да се потврди дека VEN е поврзан со сметката на корисници на комунални услуги.
• Услуги за известување: Услуга што ја користи OpenADR за да им овозможи на VEN да обезбедуваат известување за VEN. DR Програмата треба да ги специфицира барањата за известување за програмата.
• Партијата за ресурси – Ова е партијата која ги поседува ресурсите на страната на побарувачката кои можат да бидат запишани во програмите за ДР
• Ресурс – Ова е субјектот што е запишан во DR програмите и е способен да испорача некаква промена на нивниот load profile како одговор на примање DR сигнал од VTN.
• Целен клиент: Професионалецотfile на ресурси од страна на побарувачката кои можат да се запишат во специфични програми за ДР како што се станбени, индустриски или можеби врз основа на нивото на потрошувачка на електрична енергија.
• Целни оптоварувања: Ресурсите на страната на побарувачката чие оптоварување треба да се измени по приемот на a
• ВЕН – Ова е OpenADR Virtual End Node кој се користи за интеракција со VTN.
• ВТН – Ова е OpenADR виртуелниот врвен јазол што се користи за интеракција со ресурсите запишани во DR програмите.

Кратенки

• BMS: Систем за управување со згради
• C&I: Комерцијална и индустриска
• Заедница: Комуникации помеѓу два ентитета
• DR: Одговор на побарувачката
• ЕМС: Систем за управување со енергија
• OpenADR: Отворете Автоматски одговор на побарувачката
• Програми: Упатување на програма(и) за одговор на побарувачката
• ВЕН: Виртуелен краен јазол
• ВТН: Виртуелен врвен јазол

Видови програми за одговор на побарувачката

Овој документ содржи шаблони за DR програмите прикажани подолу.

 

1. Критична врвна цена: Стапката и/или структурата на цените дизајнирана да поттикне намалена потрошувачка за време на периоди на високи пазарни цени на големо или системски непредвидени ситуации со наметнување однапред одредена висока стапка или цена за ограничен број денови или часови.

2. Програма за наддавање капацитет: Програма која му овозможува на ресурсот на побарувачка на малопродажните и големопродажните пазари да понуди намалување на оптоварувањето по одредена цена или да идентификува колкав товар е подготвен да го намали по одредена цена.

 

3. Програма за резиденцијален термостат/Директна контрола на оптоварувањето: Активност за одговор на побарувачката со која спонзорот на програмата далечински ја контролира електричната опрема на купувачот (на пр. климатизер) на краток рок. Овие програми првенствено се нудат на резиденцијални или мали комерцијални клиенти.

4. Брза програма за испраќање DR / помошни услуги: Програма за одговор на побарувачката која обезбедува стимулативни плаќања на клиентите за одговор на оптоварување за време на настан за одговор на побарувачката во итни случаи. Абнормална состојба на системот (на прampле, системски ограничувања и локални ограничувања на капацитетот) што бара автоматско или непосредно рачно дејство за да се спречи или ограничи дефектот на преносните капацитети или снабдувањето со производство што може негативно да влијае на доверливоста на Масовниот електричен систем. Овој тип на програми понекогаш може да се нарекуваат „Помошни услуги“.

5. Електрично возило (EV) DR програма: Активност за одговор на побарувачката со која се менуваат трошоците за полнење на електрични возила за да предизвикаат потрошувачите да ги променат моделите на потрошувачка.

6. Програма за дистрибуирани енергетски ресурси (DER) DR: Активност за одговор на побарувачката што се користи за да се изедначи интеграцијата на дистрибуираните енергетски ресурси во паметната мрежа.

 

Сценарија за распоредување

Начинот на кој се распоредува програмата DR е донекаде независен од карактеристиките на самата програма DR. Следниве дијаграми покажуваат различни начини на кои може да се распореди програма за DR. Следниот дел дава вкрстена референца помеѓу сценаријата за распоредување и DR програмите со кои најверојатно ќе се користат.

Дијаграмите во овој дел ги прикажуваат односите помеѓу ентитетите во различните сценарија.

Директно 1

Ова е едноставно сценарио во кое постои директна врска помеѓу Програмската страна ДР и Страната со ресурси. Страната со ресурси е одговорна за запишување на сопствените ресурси во DR програмите и Мрежна инфраструктура директно комуницира со ресурсите преку VEN што се наоѓа во рамките на инфраструктурата на страната на побарувачката. Понатаму, VEN е во сопственост на страната на ресурсите и е одделен од ресурсите и нивните контролори. Кога VEN сигналот DR го прима, тој обично не имплементира никаква логика за контрола на оптоварувањето, туку едноставно ги препраќа сигналите до контролорите на оптоварување кои преземаат соодветно дејство. ПрampДеловите од ова сценарио ќе вклучуваат згради за C&I кои можат да инсталираат порта што содржи OpenADR VEN и кога сигналот е примен од таа порта, тој едноставно го преведува во некој друг протокол и го проследува до самите контролори на оптоварување.

Директно 2

Ова е многу слично на сценариото Direct 1. Главната разлика е во тоа како VEN се инстанцира и како се олеснуваат интеракциите со VTN. VEN е инстанциран во ентитет како централизиран BMS кој може да имплементира DR логика и да комуницира со Compound Resource и нивните многу различни контролери за оптоварување од поцентрализирана локација. Прampтие вклучуваат големи згради со BMS кои контролираат многу различни оптоварувања во зградата (на пр. осветлување, HVAC, индустриски процеси итн.) до вampкористи кои можат да имаат повеќе објекти со централизиран контролен систем.

Директно 3

Ова сценарио е многу слично на сценариото Direct 1. Главната разлика е во тоа што VEN е инстанциран директно во ресурсот и неговиот контролер на оптоварување. Во овој случај, DR сигналите се испраќаат директно до ресурсот и неговиот контролер на оптоварување. Таканареченото сценарио „цени за уреди“ спаѓа во оваа категорија. Прampлес би вклучил секаков вид контролер на оптоварување како што е HVAC (т.е. термостат) кој има вграден VEN кој е способен за директно интеракција со страничните ентитети на мрежата VTN.

Директно 4

Ова е комбинација од видови на сценарија Директно 1 и Директно 2. Главната разлика е во тоа што повеќе VEN се поврзани со еден сложен ресурс кој се состои од повеќе средства со свои контролери за оптоварување. Секој од контролорите за оптоварување што го сочинуваат сложениот ресурс може да биде поврзан со различен VEN. Имајте на ум дека сите VEN ќе бидат под контрола на истата Ресурсна страна која го поседува сложениот ресурс. Ова сценарио постои со цел да се олеснат инфраструктурите на страната на побарувачката кои имаат сложени ресурси, но немаат централизиран BMS како сценариото Direct 2. Прampможе да вклучуваат згради со различни контролори на оптоварување на секој кат, но без централизиран BMS, или вampкористи со различни контролери во секоја зграда, но не вampни широк контролер. Бидејќи од перспектива на страната на програмата DR, има само еден ресурс вклучен во програмата кога сака да испрати DR сигнал до ресурсот, може едноставно да ги испрати истите сигнали до секој од назначените VEN кои биле поврзани со ресурсот.

Олеснувач 1

Во ова сценарио постои посредник кој ги олеснува интеракциите помеѓу Програмската страна ДР и ресурсите. Вообичаено, Посредничката страна работи во име на Страната со ресурси за да им помогне да управуваат со нивните ресурси. Страните со ресурси имаат директни односи со Програмската страна на ДР и тие ги запишуваат сопствените ресурси во Програмите за ДР. Така Програмската партија ДР viewСекоја страна со ресурси е посебен ресурс и може да комуницира со нив поединечно. Улогата на посредничката страна е да дејствува како посредник за сите интеракции поврзани со OpenADR, така што VEN е инстанциран во рамките на посредничката инфраструктура на олеснувачот. Таквата инфраструктура често е облак бази и се нуди на страните со ресурси како софтвер како услуга (SaaS). Кога сигналот DR е примен од VEN на фасилитаторот, може да се случат голем број различни дејства, вклучително и проследување на сигналот DR до соодветниот ресурс и евентуално имплементирање на некој вид DR Logic и испраќање команди за контрола на оптоварувањето до контролорот за оптоварување на секој Ресурс. ПрampДеловите од ова сценарио вклучуваат:

• Продавачи кои управуваат со капацитетите за големи комерцијални синџири како што се продавачите на големи кутии.
• Посредници за индустриска контрола.
• Компании за енергетски услуги (ESCO's)
• Системи за управување со уреди и уреди базирани на облак, како што се новите продавачи на термостати за паметни комуникациски уреди.

Агрегатор 1

Ова сценарио е слично на сценариото Олеснувач. Главната разлика е во тоа што Агрегаторната страна има врска со Програмската страна ДР наспроти Страните со ресурси. Агрегаторската страна собира повеќе средства на клиентите во еден ресурс што го запишува во DR програмите. Програмската страна ДР нема видливост на поединечните средства со кои управува Агрегаторот. Како и кај Олеснувачот, агрегаторот има своја инфраструктура каде што е инстанциран VEN. Разликата е во тоа што кога се прима DR сигнал, тој упатува на еден ресурс и Агрегаторот имплементира некаква DR логика над сите средства во нивното портфолио за да ги постигне целите наведени во сигналот DR.

 

Сценарио за распоредување и мапирање на DR програма

Табелата подолу дава за тоа кои сценарија за распоредување се најчести за одредена програма за ДР.

	Сценарио за распоредување
Шаблон DR	Директно 1, 2, 3, 4	Олеснувач 1	Агрегатор 1
CPP програма	∆	∆
Програма за наддавање капацитет			∆
Станбен термостат Програма		∆
Брзо DR испраќање			∆
Електрично возило (EV) DR програма	∆	∆
Програма за дистрибуирани енергетски ресурси (DER) DR	∆	∆

Избор на шаблон за DR програма

Следниве се збир на прашања кои се релевантни за која било алатка која сака да имплементира нова програма за ДР. Ова не треба да биде сеопфатно, туку претставува некои од порелевантните прашања. Целта на овие прашања е да им помогнат на услужните програми да се насочат кон соодветен сет на шаблони на програмата DR.

П: Зошто сакате да се занимавате со ДР? Која состојба на мрежата или оперативен проблем се обидувате да ја ублажите со DR?

Ова е убедливо најважното прашање и ја формира основата за севкупните барања и цели за тоа што треба да постигне програмата за ДР. Одговорот на ова прашање дефинира како страната на побарувачката се оптоварува проfile се претпоставува дека е обликуван од програмата DR. Сите други барања произлегуваат од одговорот на ова прашање.

• Дали се обидувате да ги избричите врвовите?
• Дали сакате да го наполните стомакот на патката?
• Дали се обидувате да ја заштитите цената на струјата?
• Дали сте загрижени за доверливоста на мрежата?
• Дали се обидувате да ги зачувате средствата на мрежата?
• итн итн итн.

Табелата подолу дава дополнителен контекст на мотивациите кои стојат зад желбата да се развие програма за ДР

Доверливост и безбедност на мрежата	Фреквенција и волуменtagд стабилност
	Адекватност на ресурсите
	Врвен капацитет
	Rampинг
	Вонредна состојба
Набавка на енергија	Пазарни цени на место
	Цена арбитража
Управување со средства	Спречување на штети
	Намалување на одржување
	Продолжување на животниот век
Управување со капацитети	Економски придобивки
	Управување со итни случаи
Еколошки	Негават
	Чиста енергија

П: Дали веќе постои постоечка програма за ДР или тарифа за оваа програма?

• Честопати програмските правила се експлицитно наведени во тарифата.

П: Кој сегмент од пазарот на побарувачката го таргетирате со оваа програма?

Ова може да помогне да се одреди таргетирањето на ресурсите во настанот и видот на сигналот.

• Станбени
• Голем C&I
• Мали C&I
• Земјоделство
• Управување со водите
• Електрични возила
• итн, итн, итн

П: Дали се обидувате да насочите кон одредени видови товари?

• Термостати
• Електрични возила
• Ag пумпи
• итн.

П: Кој е вашиот модел на распоредување?

Одговорот на ова прашање може да влијае на тоа како се дефинираат ресурсите во рамките на програмата и да определи како тие ресурси се насочени во рамките на настаните.

• Директно до клиентите
• Преку посредници како што се агрегатори или олеснувачи
• Клиент одговорен за набавка и распоредување на сопствената VEN опрема?
• итн.

П: На кое ниво на специфичност сакате да комуницирате со оптоварувањата од страната на побарувачката?

Ова прашање е донекаде поврзано со моделот на распоредување и одредува како се дефинираат и таргетираат ресурсите во програмата. Тоа е едно од најважните и можеби најкомплексните прашања.

• Интеракција со секој поединечен ресурс
• Интеракција преку олеснувач или агрегатор без спецификација на ресурсите зад нив
• Интеракција преку олеснувач или агрегатор И наведете кои ресурси зад нив треба да бидат испратени
• Користете локација како атрибут за да наведете ресурси
• Користете некој вид на механизам за групирање дефиниран со помош за да наведете ресурси
• Насочете ги индивидуалните средства како што се термостатите
• Интерактивирајте без никакви ресурси и само емитувајте DR настани
• итн.

П: Каков образец за интеракција сакате да го употребите за да влијаете на професионалното оптоварување на вашите клиентиfiles?

Ова прашање го одредува типот на DR сигнали што ќе бидат испратени до учесниците во програмата.

• Стимулации (на пр. динамични цени)
• Вчитај испраќања (на пр. помошни услуги)
• Директна контрола на оптоварувањето
• Генерички сигнал за настан
• итн.

П: Кои се општите атрибути за распоред на ресурси на програмата?

• Датуми и времиња кога настаните може да се нарекуваат
• Фреквенција на настани
• Времетраење на настаните
• Дозволени латенции за ширење на настани
• итн.

П: Како се одредува достапноста на ресурсите во програмата?

• Со строги програмски правила
• Како дел од одреден процес на номинација или наддавање направен од ресурсот
• Дозволено е да се одјавите/исклучите?
• итн.

П: Каков вид видливост ви е потребен за перформансите на ресурсот?

Ова е многу широко прашање и одредува каков тип на информации се враќаат од ресурсите во програмата ДР. Генерално, ова го одредува типот на извештаи кои се потребни.

• Он-лајн / офлајн
• Користење (тековно и/или историски)
• Вчитај потенцијал за одговор
• Вчитај достапност
• Состојба на оптоварување/средство (тековна и/или историска)
• итн, итн итн.

Шаблони за програма за одговор на побарувачката

Програма за критични врвни цени (CPP)

Програмски карактеристики на CPP DR

Вчитај Проfile Цел	-Намалување на максималната побарувачка
Примарни драјвери	-Намалени капитални расходи и намалени трошоци за енергија
Опис на програмата	Кога комуналните претпријатија забележуваат или очекуваат високи пазарни цени на големо или вонредни услови на електроенергетскиот систем, тие може да повикаат критични настани во одреден временски период (на пр., 3-6 часот во топол летен работен ден), цената за електрична енергија во овие временски периоди е значително подигнат.
Стимулација на клиентите	На клиентите може да им бидат понудени намалени цени на енергијата во периоди кои не се шпиц како поттик за учество во програмата.
Стапка дизајн	CPP е програма за цени со стапки кои се зголемуваат за време на критичните врвови во потрошувачката на енергија. Вообичаено, стапките на CPP се собирач или множител на рамни, нивоа или основни стапки TOU.
Целен клиент	-Станбени или C&I
Целно оптоварување	- Било кој
Предуслов	-Клиентот мора да има интервално мерење -Клиентите C&I можеби ќе треба да исполнат критериум за побарувачка
Временска рамка на програмата	-Вообичаено опфаќа месеци од годината каде што се случува врвната потрошувачка на енергија, иако во некои случаи може да биде и во текот на целата година.
Ограничувања на настанот	-Вообичаено од понеделник до петок, со исклучок на празниците, со вообичаено дозволени последователни дневни настани
Денови на настанот	- Типично од 9 до 15 годишно
Времетраење на настанот	-Вообичаено за време на фиксна временска рамка за сите настани кои се движат од 4 до 6 часа за време на највисоката потрошувачка на енергија во текот на денот.
Известување	- Типично ден напред
Одлучете се за однесување	-Вообичаено од клиентите не се бара да учествуваат на настани
Сертификација Настани	-Типично ниту еден

OpenADR Карактеристики за CPP програми

Сигнали за настани	–ЕДНОСТАВЕН сигнал со нивоа од 1 до 3 мапиран на влијанието на цената на настанот CPP. Ако програмата за CPP има една компонента за цени, таа треба да биде мапирана на ниво 1. За програмите за CPP со повеќе компоненти на цени, најмалата ценовна компонента треба да биде мапирана на ниво 1, со другите ценовни компоненти мапирани на нивоа 2 и 3 во зголемен степен на влијанието на цените. -Ако распоредувањето поддржува B profile VENs, покрај сигналот SIMPLE, може да биде вклучен и сигнал ELECTRICITY_PRICE во носивоста со тип на ценаРелативна, ценаАпсолутна или ценаМултипликатор во зависност од природата на програмата. Види Анекс А за прampлес.
Одлучете ги одговорите	-ВТН кои испраќаат настани треба да го постави елементот oadrResponseRequired на „секогаш“, барајќи од VEN да одговори со optIn или optOut -Бидејќи учеството во програмата CPP е вежба за „најдобар напор“, нема формално значење да се откажете или да се откажете надвор од учтивост достапност индикација за намерата за учество. Ние го препорачуваме тоа VEN реагираат со optIn, освен ако не е преземено одредено дејствие за надминување од страна на клиентот. - Оптоварувањето на oadrCreateOpt обично нема да се користи за да се квалификуваат ресурсите што учествуваат во настани.
Опис на настанот	-Настанот приоритет треба да се постави на 1 освен ако правилата на програмата или конфигурацијата на VTN не наведат поинаку –Тест настаните обично не се користат со CPP програми. Меѓутоа, ако им се дозволи, елементот testEvent треба да се постави на „true“ за да го означи тест настанот. Доколку се потребни дополнителни параметриизирани информации во овој елемент, тој може да следи „точно“ одвоено со празно место со овие дополнителни информации.
Активен период на настанот	– eiRampНагоре, eiRecovery, елементите за толеранција обично не се користат
Основни линии	–Основните линии обично не се вклучени во товарот на настанот
Таргетирање на настани	-Програмите CPP обично не прават разлика помеѓу ресурсите за даден клиент. Таргетирањето обично го одредува venID, што укажува дека треба да учествуваат сите ресурси поврзани со VEN, или листа на сите ID на ресурси поврзани со VEN.
Услуги за известување	–Телеметриското известување обично не се користи бидејќи тоа не е апсолутно неопходно за CPP програмите. Видете во Анекс Б за прampИзвештаи од пилотите за комунални услуги кои би можеле да бидат применливи за овој тип на програма.

Одлучете ги услугите	–Користење на услугата Opt за да се соопштат привремените распореди за достапност обично не би се користеле како дел од програмата CPP. Сепак, некои распоредувања би можеле да ја користат оваа услуга за да ги зачуваат достапните денови на настани за клиентите кои укажуваат на недостапност.
Услуги за регистрација	Интервали на гласање побарано од VTN за типични CPP програми за претстојниот ден не се бара да бидат почесто од еднаш на час. Сепак, употребата на анкета за откривање на отчукувањата на срцето може да бара почести анкети.

Програма за наддавање капацитет

Карактеристики на програмата за наддавање на капацитет ДР

Вчитај Проfile Цел	-Намалување на максималната побарувачка и соодветност на ресурси
Примарни драјвери	-Намалени капитални расходи и намалени трошоци за енергија
Опис на програмата	Програмата за наддавање капацитет се користи од ISO/комуналните претпријатија за да се добие однапред посветен капацитет за отфрлање на товарот од агрегатори или од сопствени агрегирани клиенти. Овој однапред ангажиран капацитет за отфрлање на оптоварување се користи од ISO/комуналните претпријатија кога забележуваат или очекуваат високи пазарни цени, вонредни услови на електроенергетскиот систем или како дел од нормалното искористување на енергетските ресурси со повикување на настани за DR во одреден временски период.   Забележете дека секој агрегатор обично е одговорен за дизајнирање на сопствена програма за одговор на побарувачката, како и за стекнување на клиенти и известување за настани со цел да се исполнат обврските за капацитет преземени како дел од оваа програма.
Стимулација на клиентите	Агрегаторите/клиентите добиваат два вида на стимулации. Прво, тие добиваат исплата за капацитет за задржување на одредена количина на капацитет за оптоварување достапен за DR настани за време на иден временски прозорец. Второ, ако настанот се свика во текот на идниот временски прозорец, може да се изврши исплата на енергија за оптоварување што се испушта во текот на траењето на настанот.
Стапка дизајн	Учесниците во програмата поднесуваат понуда за „номинација за капацитет“ означувајќи го капацитетот за отфрлање на оптоварување што се подготвени да го задржат како достапен во идниот временски прозорец. Понудата може да го вклучи и поттикот што агрегаторот/клиентот е подготвен да го прифати за отфрлен товар под основната вредност. На пазарите за комунални услуги, посветеноста на капацитетот е типично за следниот календарски месец, иако се користат многу подолги временски рамки на ISO пазарите. Како дел од номинацијата за капацитет, клиентот може да може да избере помеѓу голем број карактеристики, вклучувајќи известување за претпладневниот ден или денот на денот и прозорецот за времетраење на настанот (како 1-4 часа, 2-6 часа, ...). Исплатата на капацитетот се врши на клиентот за оваа претходна обврска, дури и ако нема настани повикани во временскиот прозорец. Доколку настанот е повикан за време на временскиот прозорец, клиентот може да добие енергетска исплата за оптовареноста во однос на основната линија, меѓутоа може да се применат казни доколку се испорача помал од однапред посветениот капацитет на отфрлање на товар во моментот на свикување на настанот.
Целен клиент	-Агрегатори и самособрани клиенти за C&I
Целни оптоварувања	– Било кој

Предуслов	-Клиентот мора да има интервално мерење -Клиентите C&I можеби ќе треба да исполнат барање или критериум за понуда
Временска рамка на програмата	- Во секое време
Ограничувања на настанот	-Вообичаено од понеделник до петок, со исклучок на празниците, со вообичаено дозволени последователни дневни настани
Денови на настанот	-Типично максимум 30 часа месечно
Времетраење на настанот	-Типично за време на фиксен временски прозорец за сите настани за време на највисоката потрошувачка на енергија во денот.). Времетраењето на настанот варира во зависност од посветеноста на капацитетот на клиентот со преференции кои се движат од 1 до 8 часа или како што е наведено во дизајнот на програмата
Известување	-Ден пред или ден во зависност од преференциите за посветеноста на капацитетот на клиентите или дизајнот на програмата
Одлучете се за однесување	-Вообичаено клиентите ќе се одлучат за настани со оглед на тоа што тие однапред имаат посветено капацитет за ослободување на товарот.
Сертификација Настани	- Обично два годишно (тест)

OpenADR Карактеристики за капацитети за наддавање програми

Сигнали за настани	–ЕДНОСТАВЕН сигнал со нивоа од 1 до 3 мапирано на количината на оптоварување што се отфрла. Ако програмата поддржува само едно ниво на оптоварување, тоа треба да се мапира на ниво 1. За програми со повеќе нивоа на оптоварување, најмалата промена од нормалното функционирање треба да се мапира на ниво 1, со вредностите на отфрлените оптоварувања мапирани на нивоа 2 и 3 во зголемен степен на оптоварување. -Ако распоредувањето поддржува B profile VENs, покрај SIMPLE сигналот, може да биде вклучен и BID_LOAD и/или BID_PRICE сигнал во носивоста со сигнални типови на зададена точка и цена, и единици на powerReal и валута PerKW соодветно. BID_LOAD ќе го одрази бараниот отфрлен товар до износот на капацитетот што го понудил агрегаторот/клиентот, а BID_PRICE ќе ја одразува стимулативната понуда од агрегаторот/клиентот. Види Анекс А за прampлес.
Одлучете ги одговорите	-ВТН кои испраќаат настани треба да го постави елементот oadrResponseRequired на „секогаш“, барајќи од VEN да одговори со optIn или optOut -Како агрегатори/клиенти имаат однапред обврзан капацитет VEN треба да одговорат со optIn. Може да се испрати откажување како одговор на настанот, но ова е неформална индикација за достапност, а не формално откажување од настанот. -На Оптоварувањето на oadrCreateOpt обично нема да се користи за да се квалификуваат ресурсите кои учествуваат во настани бидејќи обично оптоварувањето е единечен збирен ентитет.
Опис на настанот	-Настанот приоритет треба да се постави на 1 освен ако правилата на програмата или конфигурацијата на VTN не наведат поинаку –Може да се користат тест настани со програмите Capacity Bidding. Доколку се дозволени, елементот testEvent треба да се постави на „true“ за да се означи тест настанот. Доколку се потребни дополнителни параметриизирани информации во овој елемент, тој може да следи „точно“ одвоено со празно место со овие дополнителни информации.
Активен период на настанот	– eiRampНагоре, eiRecovery, елементите за толеранција обично не се користат
Основни линии	–Основните линии обично не се вклучени во товарот на настанот бидејќи овие податоци обично не се достапни во моментот кога настанот е инициран. Сепак, и комуналните претпријатија и агрегаторите/клиентите би view вклучувањето на основните информации во настаните како корисно.
Таргетирање на настани	-Програмите за наддавање за капацитет обично не прават разлика помеѓу ресурсите за даден клиент. Таргетирањето обично го одредува venID, што укажува дека треба да учествуваат сите ресурси поврзани со VEN, или вклучува ID на ресурс претставник на збирното оптоварување поврзани со VEN.
Услуги за известување	Програмите за наддавање за капацитет на ISO обично бараат извештаи TELEMETRY_USAGE со powerReal податочни точки. Види прampлес во Анекс А. Вообичаено, не е потребно известување за телеметрија за наддавање капацитет за комунални услуги. Забележете дека известувањето за телеметрија бара B profile VENs. Видете во Анекс Б за прampИзвештаи од пилотите за комунални услуги кои би можеле да бидат применливи за овој тип на програма.
Одлучете ги услугите	–Користење на услугата Opt за да се соопштат привремените распореди за достапност обично не би се користеле како дел од програмата за наддавање капацитет бидејќи клиентите однапред ја обврзале нивната достапност. Сепак, оваа услуга може да биде корисна како неформален начин за учесниците да укажат на недостаток на достапност поради олеснителни причини како што е дефект на опремата.
Услуги за регистрација	Интервали на гласање побарано од VTN за типични програми за претстојниот ден не се бара да бидат почесто од еднаш на час. Сепак, употребата на анкети за откривање на отчукување на срцето или програми за денот може да бара почести анкети.

Програма за станбен термостат

Оваа програма е претставник на Direct Load Control (DLC) каде што сигналот за одговор на побарувачката директно го модифицира однесувањето на ресурсите за намалување на оптоварувањето, без слој на апстракција помеѓу приемот на сигналот и преземеното специфично дејство за намалување на оптоварувањето.

Програмски карактеристики на станбен термостат DR

Вчитај Проfile Цел	-Намалување на максималната побарувачка
Примарни драјвери	-Намалени капитални расходи и намалени трошоци за енергија
Опис на програмата	-Кога претпријатијата забележуваат или очекуваат високи пазарни цени на големо или вонредни услови на електроенергетскиот систем, тие може да иницираат настан што го менува однесувањето на програмибилниот термостат за комуникација (PCT) на клиентот во одреден временски период (на пр., 3:6-XNUMX:XNUMX на жешко летен работен ден) со цел да се намали потрошувачката на енергија. -Промената на однесувањето на PCT како одговор на настанот може да биде едноставна промена на поставената температура за времетраењето на настанот или покомплексен сет на промени, вклучително и претходно ладење, што го минимизира влијанието на настанот врз удобноста на клиентот ниво.
Стимулација на клиентите	-Стимулациите имаат две општи форми. Прво, на клиентите може да им се обезбеди бесплатен PCT или да им бидат понудени попусти/попусти за PCT купени од клиенти како поттик да се запишат во програмата DR. Второ, клиентите може да добијат постојана годишна стипендија за продолжување на уписот во програмата. Поретки би биле тековните стимулации што им се исплаќаат на клиентите врз основа на реално намалување на енергијата за време на настаните.
Стапка дизајн	-Првенствено програма за поттикнување, каде што клиентите добиваат попуст или бесплатни PCT за запишување во програмата за ДР. Некои програми може да плаќаат периодична стипендија или стимулативни плаќања врз основа на намалување на енергијата за време на настани.
Целен клиент	-Станбени
Целно оптоварување	-HVAC
Предуслов	-Типично нема, бидејќи клиентите добиваат PCT како дел од запишувањето на програмата
Временска рамка на програмата	-Вообичаено опфаќа месеци од годината каде што се случува врвната потрошувачка на енергија, иако во некои случаи може да биде и во текот на целата година.
Ограничувања на настанот	-Вообичаено од понеделник до петок, со исклучок на празниците, со вообичаено дозволени последователни дневни настани.
Денови на настанот	- Типично од 9 до 15 годишно
Времетраење на настанот	- Настаните може да се случат во секое време, со времетраење од 2 до 4 часа, иако обично настаните се случуваат во периодите на најголема потрошувачка на енергија во денот.
Известување	-Типично ден пред, иако некои програми може да имаат време за известување пократко од 10 минути.
Одлучете се за однесување	- Од клиентите не се бара да учествуваат во настани, но тие автоматски ќе бидат вклучени во настани, освен ако не преземат акција за да го отфрлат настанот или не направат рачно прилагодување на температурата за време на настанот.
Сертификација Настани	-Типично ниту еден

OpenADR Карактеристики за програми за резиденцијален термостат

Сигнали за настани	–ЕДНОСТАВЕН сигнал со нивоа од 1 до 3 мапиран на промената на подесената точка на температурата на PCT или процентот на термостатски циклусtagд . Ако програма за резиденцијален термостат има една компонента за поместување/возење велосипед, таа треба да се одбележи на ниво 1. За програми со повеќе компоненти за поместување/возење велосипед, најмалата промена од нормалната работа треба да се мапира на ниво 1, со другите вредности за поместување/возење мапирано на нивоата 2 и 3 со зголемен степен на влијание на отфрленото оптоварување. -Ако распоредувањето поддржува B profile VENs, покрај SIMPLE сигналот, може да биде вклучен и LOAD_CONTROL сигнал во носивоста со еден вид на x-loadControlLevelOffset или x-loadControlCapacity за да го одредите саканиот температурен поместување или процентот на термостатски циклусtage соодветно. Се препорачува повторно да се а единица тип на „температура“ што се користи во носивост со користење на сигналот x-loadControlLevelOffset да се означи Целзиус или Фаренхајт за офсет. Види Анекс А за прampлес.
Одлучете ги одговорите	-ВТН кои испраќаат настани треба да го постави елементот oadrResponseRequired на „секогаш“, барајќи од VEN да одговори со optIn или optOut – VEN треба да одговорат со optIn, освен ако не е преземено одредено дејствие за надминување од страна на клиентот. -На OadrCreateOpt носивост може да се користи од VEN да се квалификува учеството на ресурсите во некој настан. На пример, настан може да ги таргетира ID на ресурси на два термостата кои контролираат одделни системи за HVAC. Ако клиентот одлучи дека само еден од системите за климатизација може да учествува на настанот, тоа ќе биде доставено до VTN користејќи го товарот oadrCreateOpt. Забележете дека товарот oadrCreateOpt е поддржан само од B profile VENs
Опис на настанот	-Настанот приоритет треба да се постави на 1 освен ако правилата на програмата или конфигурацијата на VTN не наведат поинаку –Тест настаните обично не се користат со програми за резиденцијален термостат. Меѓутоа, ако им се дозволи, елементот testEvent треба да се постави на „true“ за да го означи тест настанот. Доколку се потребни дополнителни параметриизирани информации во овој елемент, тој може да следи „точно“ одвоено со празно место со овие дополнителни информации.
Активен период на настанот	–Рандомизацијата обично се користи за настани со термостат во станбени простории користејќи го елементот за толеранција – eiRampЕлементите Up и eiRecovery обично не се користат
Основни линии	–Основните линии обично не се вклучени во товарот на настанот
Таргетирање на настани	-Програмите за резиденцијален термостат се насочени кон ресурсите на HVAC контролирани од PCT. Таргетирањето обично ги специфицира ресурсите ID на системите HVAC (т.е. термостатот) поврзани со VEN или venID со цел класа на уред за сигнал за настан поставен на Термостат
Услуги за известување	–Телеметриското известување обично не се користи бидејќи тоа не е апсолутно неопходно за програми за термостат во станбени простории Видете во Анекс Б за прampИзвештаи од пилотите за комунални услуги кои би можеле да бидат применливи за овој тип на програма.
Одлучете ги услугите	–Користење на услугата Opt за да се соопштат привремените распореди за достапност обично не би се користеле како дел од програмата CPP.
Услуги за регистрација	Интервали на гласање побарано од VTN за типични програми за резиденцијален термостат за претстојниот ден не се бара да бидат почесто од еднаш на час. Сепак, употребата на анкета за откривање на отчукување на срцето може да бара почести анкети како што би биле програмите за термостати во домот со значително пократко време за известување.

Брзо DR испраќање

Карактеристики на програмата за брзо испраќање ДР

Вчитај Проfile Цел	-Испраќајте ресурси за да постигнете одговор на оптоварување во „реално време“
Примарни драјвери	-Доверливост на мрежата и помошни услуги
Опис на програмата	Брзото DR се користи од ISO/услужните претпријатија за да се добие однапред подготвен одговор на оптоварување во „реално време“. Овој претходно ангажиран одговор на оптоварување се користи од ISO/услужните претпријатија кога ги набљудуваат условите кои бараат итна акција за одржување на стабилноста и интегритетот на мрежата. Во реално време значи дека ресурсите обично се испраќаат со латентност која се движи од 10 минути за ресурсите што се користат како резерви до 2 секунди за ресурсите што се користат за регулациони цели. Големината на одговорот на оптоварувањето мора да биде доволно голема за да направи разлика во ублажувањето на состојбата на мрежата и затоа ресурсите се типично многу големи и често управувани од агрегатори како дел од збирниот ресурс. Минималните големини за одговор на оптоварување за ресурс да се квалификува за учество во помошни услуги обично се околу 500 kW, но може да биде и до 100 kW за некои програми. Забележете дека ако ресурсот се користи како резерва, тој вообичаено ќе биде повикан да го намали (т.е. отфрли) оптоварувањето, но ако се користи за регулациони цели, може да се испрати или да го зголеми или намали товарот.
Стимулација на клиентите	Агрегаторите/клиентите обично добиваат два типа на стимулации. Прво, тие добиваат плаќање за обврзување и ставање на располагање одредена количина на одговор на оптоварување достапна за DR настани во текот на иден временски прозорец. Износот на одговорот на оптоварувањето, временскиот прозорец на достапност и износот што треба да се плати обично го поставува агрегаторот/клиентот. Второ, ако настанот се повика за време на идниот временски прозорец, плаќањето се заснова на износот на одговорот на оптоварување во текот на траењето на настанот.
Стапка дизајн	Учесниците во програмата поднесуваат понуда што го означува одговорот на оптоварувањето што се подготвени да го стават на располагање во идниот временски прозорец. Понудата обично го вклучува и плаќањето што агрегаторот/клиентот е подготвен да го прифати за одговорот на товарот. На пазарите за комунални услуги/ISO, понудата обично се поднесува или следниот ден или денот на временскиот период за кој се презема обврската. Како дел од нивната квалификација и регистрација на пазарите, различни параметри на обвивките на перформанси се поврзани со ресурсот како што е ramp стапка и минимални и максимални оперативни граници. Ваквите параметри регулираат како ќе биде испратен. Ако понудата на учесникот е прифатена, може да му се изврши уплата на клиентот за неговата претходна обврска, дури и ако нема настани повикани во временскиот прозорец. Доколку настанот е повикан во временскиот прозорец, клиентот може да добие дополнителни плаќања за нивната изведба за време на настанот. Ваквите плаќања засновани на перформанси може да се засноваат на голем број фактори, вклучувајќи ја количината на енергија, моќноста, колку ресурсот внимателно ги следи упатствата за испраќање и плаќањето за „километражата“ што одразува колкаво е нивното оптоварување.file се бараше да се промени за време на настанот. Некои од овие параметри како што се енергијата и моќноста може да бидат во однос на основната линија.
Целен клиент	-Агрегатори и само-агрегирани клиенти за C&I
Целни оптоварувања	- Оние кои можат да одговорат на испраќања во реално време.

Предуслов	-Клиентот мора да има интервално мерење -Мора да ги исполнува барањата за минимална големина за одговорот на товарот -Мора да може да одговори на испраќањата во реално време -Типично треба да се обезбеди телеметрија во реално време што го покажува моменталниот одговор на оптоварување
Временска рамка на програмата	- Во секое време
Ограничувања на настанот	- ниеден
Денови на настанот	- ниеден
Времетраење на настанот	-Типично краток (помалку од 30 минути), но во секој случај никогаш нема да го надмине временскиот прозорец кога учесникот го ставил на располагање ресурсот кога ја поднел својата понуда.
Известување	- ниеден
Одлучете се за однесување	-Клиентите стандардно се избираат за настани, со оглед на тоа што имаат однапред подготвен одговор на оптоварување
Сертификација Настани	-Типично еден годишно (тест)

OpenADR Карактеристики за капацитети за наддавање програми

Сигнали за настани	–ЕДНОСТАВЕН сигнал со нивоа од 1 до 3 мапиран на количината на одговор на оптоварување. Ако програмата поддржува само едно ниво на одговор на оптоварување, тоа треба да се мапира на ниво 1. За програми со повеќекратни нивоа на одговор на оптоварување, најмалата промена од нормалното функционирање треба да биде мапирана на ниво 1, со вредностите на отфрлените оптоварувања мапирани на нивоа 2 и 3 во зголемен степен на одговор на оптоварување. -Ако распоредувањето поддржува B profile VENs, покрај SIMPLE сигналот, може да се вклучи и испраќање во форма на LOAD_DISPATCH сигнал во носивоста со типови на сигнал на зададена точка или триаголник и единици на powerReal. Овој сигнал ја претставува саканата „работна точка“ на оптоварувањето и може да се изрази или како апсолутна количина од mW (т.е. поставена точка) или некој релативен број на mW (т.е. делта) од моменталната работна точка на ресурсите. Види Анекс А за прampлес.
Одлучете ги одговорите	-ВТН кои испраќаат настани треба да го постави елементот oadrResponseRequired на „секогаш“, барајќи од VEN да одговори со optIn или optOut -Како агрегатори/клиенти имаат однапред обврзан капацитет VEN треба да одговорат со optIn. Може да се испрати откажување како одговор на настанот, но ова е неформална индикација за достапност, а не формално откажување од настанот. -На Оптоварувањето на oadrCreateOpt обично нема да се користи за да се квалификуваат ресурсите кои учествуваат во настани бидејќи обично оптоварувањето е единечен збирен ентитет.
Опис на настанот	-Настанот приоритет треба да се постави на 1 освен ако правилата на програмата или конфигурацијата на VTN не наведат поинаку –Може да се користат тест настани, особено при регистрација и квалификација на ресурс. Доколку се дозволени, елементот testEvent треба да се постави на „true“ за да се означи тест настанот. Доколку се потребни дополнителни параметриизирани информации во овој елемент, тој може да следи „точно“ одвоено со празно место со овие дополнителни информации.
Активен период на настанот	– Елементите за толеранција не се користат. EiRampПериодите на Up и eiRecovery обично се дел од параметрите на ресурсот кога се регистрираат и може да се користат. Поради природата на испраќањата, тие може да бидат отворени и затоа може да нема крајно време за настанот.
Основни линии	–Основните линии обично не се вклучени во товарот на настанот бидејќи овие податоци обично не се достапни во моментот на започнување на настанот. Сепак, и комуналните претпријатија и агрегаторите/клиентите би view вклучувањето на основните информации во настаните како корисно.
Таргетирање на настани	-Програмите за наддавање за капацитет обично не прават разлика помеѓу ресурсите за даден клиент. Таргетирањето обично го одредува venID, што укажува дека треба да учествуваат сите ресурси поврзани со VEN, или вклучува ID на ресурс претставник на збирното оптоварување поврзани со VEN.
Услуги за известување	Брзите DR програми обично бараат TELEMETRY_USAGE извештаи со powerReal податочни точки. Извештајот за користење ја прикажува моменталната работна точка на ресурсите и се користи од страна на Utility/ISO за да се утврди колку внимателно ресурсот ја следи испратената инструкција за испраќање. Во некои случаи телеметријата може да вклучува и други точки на податоци како што се voltagотчитувања и состојба на полнење (т.е. енергија) во случај кога ресурсите се некаква форма на складирање. Во некои случаи, фреквенцијата на известување може да биде висока на секои 2 секунди. Забележете дека известувањето за телеметрија бара B profile VENs. Види Анекс А за прampлес. Исто така, погледнете го Анекс Б за прampИзвештаи од пилотите за комунални услуги кои би можеле да бидат применливи за овој тип на програма.
Одлучете ги услугите	–Употреба на услугата Opt за да се пренесе привремената достапност распореди обично не би се користеле бидејќи клиентите однапред ја обврзале нивната достапност. Сепак, оваа услуга може да биде корисна како неформален начин за учесниците да укажат на недостаток на достапност поради олеснителни причини како што е дефект на опремата.
Услуги за регистрација	Поради ниските барања за латентност на испраќањата во реално време се користат само шеми на интеракција со туркање.

Програма за време на употреба (TOU) за резиденцијално електрично возило (EV).

Програмски карактеристики на станбени EV TOU

Вчитај Проfile Цел	Структура на стапка со која трошоците за полнење електрични возила се модифицираат за да предизвикаат потрошувачите да ги променат моделите на потрошувачка.
Примарни драјвери	Употребата на енергија во станбените простории достигнува врв во вечерните часови. Бидејќи полнењето на EV трае 4-8 часа, може да се одложи за неколку часа за да се префрлат врвовите на товарот.
Опис на програмата	Клиентите кои имаат електрично возило може да се пријават за тарифа за време на употреба на електрично возило (EV-TOU) и да добијат пониски тарифи за полнење на нивното возило за време на часовите надвор од шпицот, како што се помеѓу полноќ и 5 часот наутро, EV-TOU се понудени да ги охрабрат корисниците да ја ограничат дневната употреба на електрична енергија, кога побарувачката за електрична енергија е најголема.
Стимулација на клиентите	Помалку скапо полнење за ЕВ.
Стапка дизајн	TOU со среднодневен врв, наутро и навечер среден врв и 12:5-XNUMX:XNUMX надвор од врвот
Целен клиент	Сопственик на EV со професионалец за товарfile што го достигнува врвот во вечерните часови.
Целни оптоварувања	Полначи за ЕВ
Предуслов	Клиентот мора да има паметно броило и EV
Временска рамка на програмата	Цела година
Ограничувања на настанот	Никој
Денови на настанот	Секој ден или само во работните денови
Времетраење на настанот	5-8 часа
Известување	Клиентот е известен за нивоата на цени на нивните месечни сметки, а VTN испраќаат сигнали за настани пред ден.
Одлучете се за однесување	Обврзниците на стапката може да го променат својот план за стапки како што вообичаено би правеле со комунални услуги.
Сертификација Настани

OpenADR Карактеристики за станбени EV TOU програми

Сигнали за настани	ELECTRICITY_PRICE сигнали со нивоа на реални цени, како и SIMPLE сигнали за да се овозможи учество од 2.0a VEN Види Анекс А за прampлес.
Одлучете ги одговорите	Секогаш одлучете се со VEN
Опис на настанот	Еден настан неделно, со интервали на настани за секое ниво на цени
Активен период на настанот	Треба да се користи најмалку 24 часовно известување. Секој интервал на настани треба да го опфати нивото на стапка на TOU
Основни линии	N/A
Таргетирање на настани	Не е потребно напредно таргетирање, само таргетирање на ниво на VEN.
Услуги за известување	Не е потребно известување, сите податоци може да доаѓаат од мерачот. Видете во Анекс Б за прampИзвештаи од пилотите за комунални услуги кои би можеле да бидат применливи за овој тип на програма.
Одлучете ги услугите	Општи услуги нема да бидат релевантни за овој тип на програма.
Услуги за регистрација	Потрошувачите однапред ќе го обезбедат својот VEN со алатката за примање сигнали за цени.

Програма за цени во реално време на јавна станица за електрично возило (EV).

Јавна станица EV RTP Програмски карактеристики

Вчитај Проfile Цел	Активност за одговор на побарувачката со која се менуваат трошоците за полнење електрични возила за да се префрли реалноста на врвните цени на потрошувачите.
Примарни драјвери	Цената на струјата варира во текот на еден ден. Оваа програма има за цел поефикасно да ја усогласи цената на наплатата со цената на електричната енергија.
Опис на програмата	Јавните полначи може да постојат на работните места, на јавните паркинзи и во продавниците на мало. Оваа програма ги пренесува цените во реално време на потенцијалните полначи пред да се приклучат, за да можат да донесат информирана одлука дали да го полнат автомобилот или не.
Стимулација на клиентите	Помалку скапо полнење за време на надвор од шпицот.
Стапка дизајн	Цените може да се променатurly, но штом клиентот ќе избере да го приклучи својот автомобил, стапката се поставува за времетраењето на полнењето.
Целен клиент	Секој со ЕВ што треба да се полни додека е надвор од дома.
Целни оптоварувања	Јавни EV полначи
Предуслов	Полначите за EV мора да бидат поврзани на интернет и да се сертифицирани OpenADR2.0b или поврзани со портата OpenADR2.0b VEN.
Временска рамка на програмата	Цела година
Ограничувања на настанот	Никој
Денови на настанот	Секој ден или само во работните денови
Времетраење на настанот	1 час или подолго
Известување	Клиентот е известен за преовладувачката стапка кога избира да го приклучи својот автомобил.
Одлучете се за однесување	Клиентите може да се откажат со тоа што ќе одлучат да не наплаќаат.
Сертификација Настани

OpenADR Карактеристики за Јавна станица EV RTP програми

Сигнали за настани	ELECTRICITY_PRICE сигнализира со цени. Види Анекс А за прampлес.
Одлучете ги одговорите	Секогаш одлучете се со VEN
Опис на настанот	Настаните мора да бидат блиски и да содржат еден интервал.
Активен период на настанот	Треба да се користи најмалку 1 час известување, меѓутоа, комуналните услуги може да изберат да користат известување за претстојниот ден.
Основни линии	N/A
Таргетирање на настани	Не е потребно напредно таргетирање, но таргетирањето може да се користи за испраќање цени до одредени трансформатори, фидери или географски области.
Услуги за известување	Не е потребно известување, но може да се користи ако сакате. Видете во Анекс Б за прampИзвештаи од пилотите за комунални услуги кои би можеле да бидат применливи за овој тип на програма.
Одлучете ги услугите	Општи услуги нема да бидат релевантни за овој тип на програма.
Услуги за регистрација	Продавач на станица за полнење ќе ги обезбеди своите уреди со VTN на комуналните услуги.

Програма за дистрибуирани енергетски ресурси (DER) DR

Следниот опис на програмата е хипотетички и се заснова на истражувачки труд (референтен труд на Риш) кој опишува како клиентите на комуналните услуги можат да ги користат ресурсите за складирање на DER за да учествуваат во програмите за DR, како што се програмите за цени во реално време (RTP).

Карактеристики на програмата за дистрибуирани енергетски ресурси (DER).

Вчитај Проfile Цел	Активност за одговор на побарувачката што се користи за да се изедначи интеграцијата на дистрибуираните енергетски ресурси во паметната мрежа.
Примарни драјвери	-Намалени капитални расходи и намалени трошоци за енергија
Опис на програмата	Клиентите со DER ресурси кои можат да соберат енергија и да ја складираат може да ги минимизираат трошоците за купување електрична енергија од мрежата за време на високи ценовни периоди со тоа што прво ќе ги искористат складираните енергетски ресурси, а потоа ќе имплементираат стратегии за намалување на оптоварувањето
Стимулација на клиентите	Способност да се контролираат трошоците за време на високи цени на електричната енергија преку искористување на складираната енергија генерирана преку PV или други средства и имплементација на стратегии за намалување на оптоварувањето
Стапка дизајн	Цените на електричната енергија варираат во зависност од пазарните цени на големо или тарифата која варира во зависност од времето од денот, сезоната или температурата
Целен клиент	Клиенти со ресурси за складирање енергија
Целни оптоварувања	Било кој
Предуслов	Ресурси за складирање на енергија
Временска рамка на програмата	Во секое време
Ограничувања на настанот	Никој
Денови на настанот	Секој ден
Времетраење на настанот	24 часа
Известување	Ден напред
Одлучете се за однесување	N/A – Програма за најдобри напори
Сертификација Настани	Никој

OpenADR Карактеристики за дистрибуирани енергетски ресурси (DER)

Сигнали за настани	ELECTRICITY_PRICE сигнализира со 24 едночасовни интервали на цени во период од 24 часа. Овој сигнал ќе бара B profile. Оваа програма не се приспособува на ЕДНОСТАВНА сигнализација за професионалецfile VENs. Види Анекс А за прampлес.
Одлучете ги одговорите	-ВТН кои испраќаат настани треба да го постави елементот oadrResponseRequired на „никогаш“, спречувајќи VEN да реагираат.
Опис на настанот	-Настанот приоритет треба да се постави на 1 освен ако правилата на програмата или конфигурацијата на VTN не наведат поинаку
Активен период на настанот	24 часа со интервали од 1 час со известување пред ден
Основни линии	N/A
Таргетирање на настани	Не е потребно напредно таргетирање освен venID
Услуги за известување	Не е потребно известување Видете во Анекс Б за прampИзвештаи од пилотите за комунални услуги кои би можеле да бидат применливи за овој тип на програма.
Одлучете ги услугите	Не се користи
Услуги за регистрација	Интервали на гласање побарано од VTN за типични програми за претстојниот ден не се бара да бидат почесто од еднаш на час. Сепак, употребата на анкета за откривање на отчукување на срцето може да бара почести анкети како што би биле програмите за термостати во домот со значително пократко време за известување.

– СampШаблони за податоци и носивост

Следниве табели и XML носивост sampлес ќе им обезбеди на имплементаторите опипливи прampза тоа како треба да се имплементираат шаблоните за ДР во овој документ. Следниве префикси на именскиот простор се користат во носивоста на прamples:

• xmlns:oadr=”http://openadr.org/oadr-2.0b/2012/07″
• xmlns:pyld=”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
• xmlns:ei=”http://docs.oasis-open.org/ns/energyinterop/201110″
• xmlns:scale=”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
• xmlns:emix="http://docs.oasis-open.org/ns/emix/2011/06"
• xmlns:strm=”urn:ietf:params:xml:ns:icalendar-2.0:stream”
• xmlns:xcal=”urn:ietf:params:xml:ns:icalendar-2.0″
• xmlns:power="http://docs.oasis-open.org/ns/emix/2011/06/power"

Програма за критични врвни цени (CPP)

Сценарио 1 за CPP – Случај за едноставна употреба, A или B Profile

• Настан
  • Известување: Ден пред настанот
  • Почеток: 1 часот
  • Времетраење: 4 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 1
  • Име на сигналот: SIMPLE
    • Тип на сигнал: ниво
    • Единици: N/A
    • Број на интервали 1
    • Интервал Времетраење(и): 4 часа
    • Типични интервални вредности: 1
    • Цел на сигналот: N/A
  • Цел(и) на настан: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

CPP Сценарио 2 – Типичен случај на употреба, B profile

• Настан
  • Известување: Ден пред настанот
  • Време на започнување: 1 часот
  • Времетраење: 4 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 2
  • Име на сигналот: Едноставно
    • Тип на сигнал: ниво
    • Единици: Ниво 0, 1, 2, 3
    • Број на интервали 1
    • Интервал Времетраење(и): 4 часа
    • Типични интервални вредности: 1 или 2
    • Цел на сигналот: Нема
  • Име на сигналот: ELECTRICITY_PRICE
    • Тип на сигнал: цена
    • Единици: УСД по Kwh
    • Број на интервали 1
    • Интервал Времетраење(и): 4 часа
    • Типични интервални вредности: од 0.10 до 1.00 долари
    • Цел на сигналот: Нема
  • Цели на настанот: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

CPP Сценарио 3 – Случај на сложена употреба

• Настан
  • Известување: Ден пред настанот
  • Почеток: 2 часот
  • Времетраење: 6 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали:2
  • Име на сигналот: Едноставно
    • Тип на сигнал: ниво
    • Единици: Ниво 0,1, 2, 3)
    • Број на интервали 3
    • Интервал Времетраење(и): 1 час, 4 часа, 1 час
    • Типични интервални вредности: 1, 2, 1 (за секој интервал соодветно)
    • Цел на сигналот: Нема
  • Име на сигналот: ELECTRICITY_PRICE
    • Тип на сигнал: цена
    • Единици: УСД по Kwh
    • Број на интервали 3
    • Интервал Времетраење(и): 1 час, 4 часа, 1 час
    • Типични интервални вредности: 0.50 $, 0.75 $, 0.50 $ (за секој интервал соодветно)
    • Цел на сигналот: Нема
  • Цели на настанот: Resource_1, Resource_2, Resource_3
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

CPP Сample Event Payload – Typical 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

ELECTRICITY_PRICE

цена

SIG_02

валута PerKWh

американски долари

ниеден

0.0

venID_1234

секогаш

Програма за наддавање капацитет (CBP)

CBP Сценарио 1 - Едноставна употреба, A или B Profile

• Настан
  • Известување: Ден пред настанот
  • Почеток: 1 часот
  • Времетраење: 4 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 1
  • Име на сигналот: SIMPLE
    • Тип на сигнал: ниво
    • Единици: N/A
    • Број на интервали 1
    • Интервал Времетраење(и): 4 часа
    • Типични интервални вредности: 1
    • Цел на сигналот: N/A
  • Цел(и) на настан: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

CBP Сценарио 2 – Типичен случај на употреба, Б проfile

• Настан
  • Известување: Ден пред настанот
  • Време на започнување: 1 часот
  • Времетраење: 4 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 2
  • Име на сигналот: Едноставно
    • Тип на сигнал: ниво
    • Единици: Ниво 0,1, 2, 3
    • Број на интервали 1
    • Интервал Времетраење(и): 4 часа
    • Типични интервални вредности: 1 или 2
    • Цел на сигналот: Нема
  • Име на сигналот: BID_LOAD
    • Тип на сигнал: поставена точка
    • Единици: powerReal
    • Број на интервали 1
    • Интервал Времетраење(и): 4 часа
    • Типична интервална вредност(и): 20kW до 100kW
    • Цел на сигналот: Нема
  • Цели на настанот: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

CBP Сценарио 3 – Случај за сложена употреба

• Настан
  • Известување: Ден на настанот (колку часа?)
  • Почеток: 1 часот
  • Времетраење: 6 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали:3
  • Име на сигналот: Едноставно
    • Тип на сигнал: ниво
    • Единици: Ниво 0,1, 2, 3)
    • Број на интервали: 2
    • Интервал Времетраење(и): 3 часа, 3 часа
    • Типични интервални вредности: 1, 2 (за секој интервал соодветно)
    • Цел на сигналот: Нема
  • Име на сигналот: BID_LOAD
    • Тип на сигнал: поставена точка
    • Единици: powerReal
    • Број на интервали 2
    • Интервал Времетраење(и): 3 часа, 3 часа
    • Типични интервални вредности: 40 kW, 80 kW (за секој интервал соодветно)
    • Цел на сигналот: Нема
  • Име на сигналот: BID_PRICE
    • Тип на сигнал: цена
    • Единици: валута PerKW
    • Број на интервали 1
    • Интервал Времетраење(и): 6 часа
    • Типични интервални вредности: 3.10 $
    • Цел на сигналот: Нема
  • Цели на настанот: Resource_1, Resource_2, Resource_3
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештај(и)
  • Име на извештајот: TELEMETRY_USAGE
  • Тип на извештај: користење
  • Единици: powerReal
  • Тип на читање: Директно читање
  • Фреквенција на известување: на секои 1 час

ЦБП Сample Event Payload – Typical 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 часот
  • Времетраење: 4 часа
  • Рандомизација: 10 минути
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 1
  • Име на сигналот: SIMPLE
    • Тип на сигнал: ниво
    • Единици: N/A
    • Број на интервали 1
    • Интервал Времетраење(и): 4 часа
    • Типични интервални вредности: 1
    • Цел на сигналот: N/A
  • Цел(и) на настанот: Ресурс_1
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

Резиденцијален термостат Сценарио 2 – типичен случај на употреба, B profile

• Настан
  • Известување: Ден пред настанот
  • Време на започнување: 1 часот
  • Времетраење: 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 часот
  • Времетраење: 6 часа
  • Рандомизација: 10 минути
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали:3
  • Име на сигналот: Едноставно
    • Тип на сигнал: ниво
    • Единици: Ниво 0,1, 2, 3)
    • Број на интервали: 2
    • Интервал Времетраење(и): 3 часа, 3 часа
    • Типични интервални вредности: 1, 2 (за секој интервал соодветно)
    • Цел на сигналот: Нема
  • Име на сигналот: BID_LOAD
    • Тип на сигнал: x-loadControlCapacity
    • Единици: Нема
    • Број на интервали 2
    • Интервал Времетраење(и): 3 часа, 3 часа
    • Типични интервални вредности: 0.9, 0.8 (за секој интервал соодветно)
    • Цел на сигналот: Нема
  • Цели на настанот: Resource_1, Resource_2, Resource_3
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN очекуван одговор: optIn, Possible OutOut (oadrCreateOpt)
• Извештај(и)
  • Никој

Станбен термостат Сample Event Payload – Typical 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 часот
  • Времетраење: 0 (Отворено заврши)
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 1
  • Име на сигналот: SIMPLE
    • Тип на сигнал: ниво
    • Единици: N/A
    • Број на интервали 1
    • Времетраење на интервалот: 0 (отворено завршено)
    • Типични интервални вредности: 1
    • Цел на сигналот: N/A
  • Цел(и) на настан: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

Брзо DR Сценарио 2 – Типичен случај на употреба, B profile

• Настан
  • Известување: 10 минути
  • Време на започнување: 1 часот
  • Времетраење: 30 минути
  • Рандомизација: Нема
  • Ramp Нагоре: 5 минути
  • Закрепнување: 5 минути
  • Број на сигнали: 2
  • Име на сигналот: Едноставно
    • Тип на сигнал: ниво
    • Единици: Ниво 0,1, 2, 3
    • Број на интервали 1
    • Интервал Времетраење(и): 30 минути
    • Типични интервални вредности: 1 или 2
    • Цел на сигналот: Нема
  • Име на сигналот: LOAD_DISPATCH
    • Тип на сигнал: делта
    • Единици: powerReal
    • Број на интервали 1
    • Интервал Времетраење(и): 30 минути
    • Типични интервални вредности: 500 kW до 2 mW
    • Цел на сигналот: Нема
  • Цели на настанот: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Име на извештајот: TELEMETRY_USAGE
  • Тип на извештај: користење
  • Единици: powerReal
  • Тип на читање: Директно читање
  • Фреквенција на известување: на секои 1 минута

Брзо ДР Сценарио 3 – Случај за сложена употреба

• Настан
  • Известување: 10 минути
  • Почеток: 1 часот
  • Времетраење: 30 минути
  • Рандомизација: Нема
  • Ramp Нагоре: 5 минути
  • Закрепнување: 5 минути
  • Број на сигнали:2
  • Име на сигналот: Едноставно
    • Тип на сигнал: ниво
    • Единици: Ниво 0,1, 2, 3)
    • Број на интервали: 2
    • Интервал Времетраење(и): 15 минути, 15 минути
    • Типични интервални вредности: 1, 2 (за секој интервал соодветно)
    • Цел на сигналот: Нема
  • Име на сигналот: LOAD_DISPATCH
    • Тип на сигнал: поставена точка
    • Единици: powerReal
    • Број на интервали 2
    • Интервал Времетраење(и): 15 минути, 15 минути
    • Типични интервални вредности: 800 kW, 900 kW (за секој интервал соодветно)
    • Цел на сигналот: Нема
  • Цели на настанот: Resource_1
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештај(и)
  • Име на извештајот: TELEMETRY_USAGE
  • Тип на извештај: користење
  • Единици: powerReal и voltage
  • Тип на читање: Директно читање
  • Фреквенција на известување: на секои 5 секунди

Брзиот ДР Сample Event Payload – Typical 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

секогаш

Брзиот ДР СampИзвештај за оптоварување со метаподатоци – Типичен B Profile Случај за употреба

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

ресурс 1

употреба

RealEnergy

В

к

Директно читање

http://MarketContext1

<oadr:oadrSamplingRate>

PT1M

PT10M

лажни

</oadr:oadrSamplingRate>

0

ReportSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

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

ec27de207837e1048fd3

Брзиот ДР Сample Пријавете барање за носивост – Типично B Profile Случај за употреба

ReportReqID130615_192625_230

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

PT1M

PT1M

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

PT10M

rID120615_122512_981_0

x-неприменливо

VEN130615_192312_582

Брзиот ДР СampПријавете оптоварување со податоци – Типично 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

ReportSpecID120615_122512_481_2

TELEMETRY_USAGE

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

VEN130615_192312_582

Програма за време на употреба (TOU) за резиденцијално електрично возило (EV).

Забележете дека како што програмата ги комуницира нивоата на стапка во прилично структурирана форма се прикажани само едноставните и типични случаи на употреба

Резиденцијално EV Сценарио 1 – Едноставна футрола за употреба, A или B Profile

• Настан
  • Известување: Ден пред настанот
  • Почеток: 1 часот
  • Времетраење: 24 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 1
  • Име на сигналот: SIMPLE
    • Тип на сигнал: ниво
    • Единици: N/A
    • Број на интервали; еднаквите TOU нивоа се менуваат за 24 часа (2 – 6)
    • Времетраење на интервал: активна временска рамка на ниво TOU (т.е. 6 часа)
    • Типични интервални вредности: 0 – 4 мапирани на TOU нивоа
    • Цел на сигналот: N/A
  • Цел(и) на настан: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

Станбено EV Сценарио 2 – Типичен случај на употреба, B profile

• Настан
  • Известување: Ден пред настанот
  • Време на започнување: полноќ
  • Времетраење: 24 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 2
  • Име на сигналот: Едноставно
    • Тип на сигнал: ниво
    • Единици: Ниво 0, 1, 2, 3
    • Број на интервали: еднаква промена на нивото TOU за 24 часа (2 – 6)
    • Времетраење на интервал: активна временска рамка на ниво TOU (т.е. 6 часа)
    • Типични интервални вредности: 0 – 4 мапирани на нивоа TOU (0 – најевтино ниво)
    • Цел на сигналот: Нема
  • Име на сигналот: ELECTRICITY_PRICE
    • Тип на сигнал: цена
    • Единици: УСД по Kwh
    • Број на интервали: еднакви промени на нивоата TOU за 24 часа (2 – 6)
    • Времетраење на интервал: активна временска рамка на ниво TOU (т.е. 6 часа)
    • Типични интервални вредности: 0.10 $ до 1.00 $ (тековна стапка на нивоа)
    • Цел на сигналот: Нема
  • Цели на настанот: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

Станбена ЕВ Сample Event Payload – Typical 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

ELECTRICITY_PRICE

цена

SIG_02

валута PerKWh

американски долари

ниеден

0.0

venID_1234

секогаш

Програма за цени во реално време на јавна станица за електрично возило (EV).

Забележете дека бидејќи ова е програма за цени во реално време, навистина нема разлика помеѓу едноставна, типична и сложена употреба. Затоа сampПодатоците ќе бидат прикажани само за типичен случај на употреба.

Јавна станица EV Сценарио 1 – Типичен случај на употреба, B profile

• Настан
  • Известување: 1 час однапред
  • Време на започнување: 1 часот
  • Времетраење: 1 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 1
  • Име на сигналот: ELECTRICITY_PRICE
    • Тип на сигнал: цена
    • Единици: УСД по Kwh
    • Број на интервали 1
    • Интервал Времетраење(и): 1 часа
    • Типични интервални вредности: од 0.10 до 1.00 долари
    • Цел на сигналот: Нема
  • Цели на настанот: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: секогаш
  • VEN Очекуван одговор: optIn
• Извештаи
  • Никој

Јавна станица ЕВ Сample Event Payload – Typical 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

ELECTRICITY_PRICE

цена

SIG_01

валута PerKWh

американски долари

ниеден

0.0

venID_1234

секогаш

Програма за дистрибуирани енергетски ресурси (DER) DR

Забележете дека бидејќи ова е програма за цени во реално време, навистина нема разлика помеѓу едноставна, типична и сложена употреба. Затоа сampПодатоците ќе бидат прикажани само за типичен случај на употреба.

Јавна станица EV Сценарио 1 – Типичен случај на употреба, B profile

• Настан
  • Известување: Ден напред
  • Време на започнување: полноќ
  • Времетраење: 24 часа
  • Рандомизација: Нема
  • Ramp Горе: Никој
  • Обнова: Нема
  • Број на сигнали: 24
  • Име на сигналот: ELECTRICITY_PRICE
    • Тип на сигнал: цена
    • Единици: УСД по Kwh
    • Број на интервали 1
    • Интервал Времетраење(и): 1 часа
    • Типични интервални вредности: од 0.10 до 1.00 долари
    • Цел на сигналот: Нема
  • Цели на настанот: venID_1234
  • Приоритет: 1
  • Потребен е одговор VEN: никогаш
  • VEN Очекуван одговор: n/a
• Извештаи
  • Никој

Јавна станица ЕВ Сample Event Payload – Typical 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

ELECTRICITY_PRICE

цена

SIG_01

валута PerKWh

американски долари

ниеден

0.0

venID_1234

никогаш

- Прample Извештаи од пилотите за комунални услуги

Членовите на OpenADR Alliance го обезбедија следниов B Profile oadrUpdateПријави носивост sampпомалку од корисни пилот програми каде што биле распоредени нивните VEN. Следниве белешки ги придружуваа трите носивост сampобезбедени:

Цел на оптоварување на термостат:

• Треба да се знае статусот на термостатот (температура, подесени точки, состојба на вентилатор и режим)
• Доколку е вклучено, без разлика дали клиентот ги променил поставките на термостатот (пораки за рачно отфрлање)

M&V за попусти Цел на носивост:

• Статус на ресурсите и рачно отфрлање во случај да се вклучите
• Податоци за интервал од KYZ пулсен бројач или енергетски монитор за вкупна енергија во KWH и моментална побарувачка во KW

Цел на оптоварување со податоци за паметен мерач/ИМИ интервал:

• Интервалот на читање на метар AMI е околу 15 минути до 1 час. Иако е корисен, не е доволно грануларен за проценки за наплата речиси во реално време
• Вкупна енергија во KWH, делта енергија во KWH, моментална побарувачка во KW

Следниве префикси на именскиот простор се користат во носивоста на прamples:

• xmlns:oadr=”http://openadr.org/oadr-2.0b/2012/07″
• xmlns:pyld=”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
• xmlns:ei=”http://docs.oasis-open.org/ns/energyinterop/201110″
• xmlns:scale=”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
• xmlns:emix="http://docs.oasis-open.org/ns/emix/2011/06"
• xmlns:strm=”urn:ietf:params:xml:ns:icalendar-2.0:stream”
• xmlns:xcal=”urn:ietf:params:xml:ns:icalendar-2.0″
• xmlns:power="http://docs.oasis-open.org/ns/emix/2011/06/power"

Извештај за оптоварување на термостатот 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

Без квалитет - без вредност

РП21

REQ:RReq:1395368583267

0013A20040980FAE

TELEMETRY_STATUS

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

VEN.ID:1395090780716

M&Vfor попусти Извештај за носивост Сample

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

Добар квалитет - неспецифичен

РП15

REQ:RReq:10453335019195698

0000000000522613 60

TELEMETRY_USAGE

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

VEN.ID:1439831430142

Паметен мерач/Интервал на податоци AMI извештај за носивост Сample

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

Нема нова вредност - користена претходна вредност

intervalDataIslivered

0.051000

Нема нова вредност - користена претходна вредност

currSumИспорачано

12172.052000

Нема нова вредност - користена претходна вредност

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

PT15S

моменталнаПобарувачка

6.114000

Нема нова вредност - користена претходна вредност

intervalDataIslivered

0.051000

Нема нова вредност - користена претходна вредност

currSumИспорачано

12172.052000

Нема нова вредност - користена претходна вредност

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

PT15S

моменталнаПобарувачка

6.113000

Нема нова вредност - користена претходна вредност

intervalDataIslivered

0.051000

Нема нова вредност - користена претходна вредност

currSumИспорачано

12172.142000

Нема нова вредност - користена претходна вредност

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

PT15S

моменталнаПобарувачка

6.112000

Нема нова вредност - користена претходна вредност

intervalDataIslivered

0.051000

Нема нова вредност - користена претходна вредност

currSumИспорачано

12172.142000

Нема нова вредност - користена претходна вредност

РП4101

<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 за да се покаже дали ресурсите ќе учествуваат на настанот. Единствената услуга поддржана од А проfile е EiEvent
• Услуга за EiReport – Се користат од VEN и VTN за размена на извештаи за историски, телеметрија и прогноза
• Услуга EiOpt – Се користи од VEN за да се пренесе привремениот распоред за достапност на VTN или да се квалификуваат ресурсите што учествуваат на настан
• Услуга EiRegisterParty – Инициран од VEN и се користи и од VEN и од VTN за размена на информации потребни за да се обезбеди интероперабилна размена на носивост
• Услуга OadrPoll – Се користи од VEN за анкета на VTN за носивост од која било друга услуга

А и Б проfile сервисните операции се дефинирани со основниот елемент на секоја носивост, со исклучок на обвивките oadrPayload и oadrSignedObject што се користат на сите B profile носивост.

– Дефиниции за носивост

Товари на EiEvent

• oadrRequestEvent – Се користи во моделот за размена на повлекување од страна на VEN за да се преземат сите релевантни настани од VTN. Се користи како примарен механизам за гласање за А проfile VEN, но се користат само на B VEN за синхронизација со VTN.
• oadrDistributeEvent – Се користи од VTN за доставување настани за одговор на побарувачката до VEN
• oadrCreatedEvent – Се користи од страна на VEN за да соопшти дали има намера да учествува на настан со избирање или исклучување
• oadrОдговор – Се користи од страна на VTN за да се потврди приемот на optIn или optOut од VEN

EiReport носивост

Имајте предвид дека и VEN и VTN се способни да бидат и производител на извештаи и барател на извештаи, така што сите носивост подолу може да бидат иницирани од која било страна.

• oadrRegisterReport – Се користат за објавување на нивните способности за известување во извештај за метаподатоци
• oadrRegisteredReport -Потврдете го приемот на oadrRegisterReport, опционално побарајте еден од понудените извештаи
• oadrCreateReport – Се користи за барање извештај кој претходно бил понуден од VEN или VTN
• oadrCreatedReport – Потврдете го приемот на барање за извештај
• oadrUpdateReport -Доставете баран извештај кој содржи податоци за интервал
• oadrUpdatedReport – Потврдете го приемот на доставен извештај
• oadrОткажи Извештај – Откажете го претходно бараниот периодичен извештај
• oadrОткажи извештај – Потврдете го откажувањето на периодичниот извештај
• oadrОдговор – Се користи како одговор на заштитник на место во некои обрасци за размена на влечење кога одговорот на слојот на апликацијата се доставува во барање за транспортен слој.

EiOpt носивост

• oadrCreateOpt – Се користи за две различни намени
  • За VEN да комуницира со привремен распоред за достапност на VTN во врска со неговата способност да учествува во настани за DR
  • За VEN да ги квалификува ресурсите кои учествуваат на некој настан
• oadrCreatedOpt – Потврдете го приемот на товарот oadrCreateOpt
• oadrCancelOpt -Откажи привремен распоред за достапност
• oadrCanceledOpt – Потврдете привремено откажување на извештајот за достапност

 

EiRegisterParty носивост

• oadrQueryRegistration – Начин за VEN да ги бара информациите за регистрација на VTN без реално да се регистрира.
• oadrCreatePartyRegistration – Барање од VEN до VTN да се регистрирате. Содржи информации за можностите на VEN.
• oadrCreatedPartyRegistration – Одговор или на oadrQueryRegistration или на oadrCreatePartyRegistration. Содржи VTN способности и информации за регистрација неопходни за VEN да функционира
• oadrCancelPartyRegistration – Се користи или од VEN или од VTN за откажување на регистрацијата
• oadrCanceledPartyRegistration – Одговор на oadrCancelPartyRegistration. Го потврдува приемот на откажувањето на регистрацијата
• oadrRequestРегистрација – Оваа носивост се користи од страна на VTN во модел за размена на повлекување за да му сигнализира на VEN повторно да ја започне низата на регистрација
• oadrОдговор – Се користи како одговор на заштитник на место во некои обрасци за размена на влечење кога одговорот на слојот на апликацијата се доставува во барање за транспортен слој.

Оптоварувања на OadrPoll

• oadrАнкета – Генерален механизам за полирање за B profile што враќа носивост за која било друга услуга што е нова или ажурирана.
• oadrОдговор – Се користи за да покаже дека нема достапни нови или ажурирани носивост

– Речник на елементи на оптоварување на шема

Следното е азбучен список на елементи на шема што се користат во носивоста на OpenADR 2.0. Наративот ја опишува нивната употреба како што се однесува на OpenADR и нивната употреба во носивоста. Кога дефиницијата на елементот се менува врз основа на товарот што е содржан во или неговиот контекст на употреба, тоа ќе биде забележано во наративот. Дефинициите за корисен товар се исклучени како што се дефинирани во Анекс В.

• ac – Булова вредност што покажува дали производот за напојување е наизменична струја
• точност - Бројот е во исти единици како и променливата за носивост за интервал. Кога е присутна со Доверба, ја покажува веројатната варијабилност на предвидувањето. Кога е присутен со ReadingType, укажува на веројатна грешка при читањето.
• збирен јазол - Збирен јазол за цени е специјализиран тип на јазол за цени што се користи за моделирање ставки како што се системска зона, стандардна ценовна зона, зона на приспособена цена, контролна област, агрегирана генерација, збирно учество на товар, збирно неучествувачко оптоварување, центар за тргување, зона DCA
• достапни – Објект кој содржи датум-време и времетраење за распоред за достапност на EiOpt
• основна ID - Единствен ID за одредена основна линија
• основно име - Описно име за основната линија
• компоненти –
• доверба – Статистичка веројатност дека пријавената податочна точка е точна
• создаденДатумВреме - ДатумВреме е креиран товарот
• валута –
• валута PerKW –
• валута PerKWh –
• валута PerThm –
• струја –
• моментална вредност - Вредноста payloadFloat на интервалот на настанот што моментално се извршува.
• прилагодена единица – Се користи за дефинирање на прилагодена единица мерка за сопствени извештаи
• датум-време –
• dtstart - Почетното време за активноста, податоците или состојбата се менуваат
• времетраење – Временски период за настан, известување или временски интервал на достапност
• времетраење - Времетраењето на активноста, податоци или состојба
• eiActivePeriod - Временски рамки релевантни за целокупниот настан
• eiCreatedEvent - Одговорете на DR настан со optIn или optOut
• eiEvent -Објект кој ги содржи сите информации за еден настан
• eiEventBaseline - Б проfile
• eiEventSignal – Објект кој ги содржи сите информации за еден сигнал во настан
• eiEventSignals - Податоци за интервал за еден или повеќе сигнали за настан и/или основни линии
• eiMarketContext – URI уникатно идентификува програма за одговор на побарувачката
• eiReportID - Референтен ID за извештај
• eiRequestEvent - Побарајте настан од VTN во режим на повлекување
• eiResponse - Наведете дали примениот товар е прифатлив
• eiTarget - Ги идентификува ресурсите поврзани со логичкиот интерфејс VEN. За настани, наведените вредности се целта за настанот
• endDeviceAsset - EndDeviceAssets се физички уред или уреди кои би можеле да бидат метри или други видови уреди што може да бидат од интерес
• енергетска очигледна - Очигледна енергија, мерена во волти-ampпред часови (VAh)
• енергијаСтавка –
• енергијаРеактивна - Реактивна енергија, волт-ampима реактивни часови (VARh)
• енергија Реална - Реална енергија, ват часови (Wh)
• дескриптор на настани - Информации за настанот
• ID на настан - ID вредност што идентификува специфичен пример за настан DR.
• настан Одговор – Објект кој содржи VEN одговор на барање за учество во настан
• Одговори на настанот - Одговори за примени или исклучување за примени настани
• настан Статус – Тековниот статус на настанот (далеку, блиску, активен, итн.)
• Колекција на карактеристики/локација/Полигон/надворешност/Линеарен прстен
• фреквенција –
• грануларност – Ова е временскиот интервал помеѓу сampводени податоци во барање за извештај.
• ID на група -Овој тип на цел се користи за настани, извештаи и распореди за избор. Вредноста вообичаено би ја доделила услужната компанија за време на запишувањето во програма за ДР
• Име на група – Овој тип на цел се користи за настани, извештаи и распореди за избор. Вредноста вообичаено би ја доделила услужната компанија за време на запишувањето во програма за ДР
• херци –
• интервал – Објект кој содржи податоци-време и/или времетраење, и активна вредност во случај на настан или податоци во случај на извештај
• интервали - Еден или повеќе временски интервали за време на кои настанот DR е активен или се достапни податоци за извештајот
• Опис - Опис на извештајната единица мерка
• ставка Единици - Основна единица мерка за точка на податоци за извештај
• пазарен контекст - URI што идентификува програма за DR
• meterAsset - MeterAsset е физички уред или уреди што ја извршуваат улогата на мерачот
• модификација Датум Време - Кога настанот е изменет
• број на модификација - Се зголемува секој пат кога некој настан се менува.
• измена Причина - Зошто настанот е изменет
• мрид - mRID го идентификува физичкиот уред што може да биде CustomerMeter или други видови на EndDevices.
• јазол - Јазолот е место каде што нешто се менува (често сопственост) или се поврзува на мрежата. Многу јазли се поврзани со метри, но не сите се.
• numData Извори –
• oadrКапацитет –
• oadrТековна –
• oadrDataQuality –
• oadrDeviceClass - Целна класа на уреди – користете само endDeviceAsset.
• oadrEvent - Објект кој содржи настан за одговор на побарувачката
• oadrЕкстензија –
• oadrExtensionName –
• oadrЕкстензии –
• oadrHttpPullModel – Бул што покажува дали VEN сака да користи модел за размена на влечење
• oadrInfo - Клучна вредност пар на информации за регистрација специфични за услугата
• oadrKey –
• oadrLevelOffset –
• oadrLoadControlState –
• oadrManual Override – Ако е точно, тогаш контролата на товарот е рачно отфрлена
• oadrMax –
• oadrMaxPeriod - Максимална сampпериод на линг
• oadrMin –
• oadrMinPeriod – Минимум сampпериод на линг
• oadrНормално –
• oadrOnChange - Ако е точно, тогаш податоците ќе се евидентираат кога ќе се променат, но не со поголема фреквенција од онаа наведена во minPeriod.
• oadrOnline – Ако е точно, тогаш ресурсот/средството е онлајн, ако е неточно тогаш офлајн.
• oadrPayload –
• oadrPayloadResourceStatus – Информации за статусот на тековните ресурси
• oadrPending Reports – Список на периодични извештаи сè уште активни
• oadrPercentOffset –
• oadrProfile - Проfile поддржано од VEN или VTN
• oadrProfileИме - OpenADR проfile име како 2.0a или 2.0b.
• oadrProfiles - OpenADR проfileе поддржан од имплементацијата
• oadrИзвештај -Објект кој ги содржи сите информации за еден извештај
• oadrОпис на извештај – Опис на карактеристиките на извештајот понудени од производителот на извештајот. Содржани во извештај за метаподатоци
• oadrReportOnly - ReportOnlyDevice Flag
• oadrReportPayload – Вредности на податочни точки за извештаи
• oadrRequestedOadrPollFreq - VEN ќе испрати оптоварување на oadrPoll до VTN најмногу еднаш за секое времетраење одредено со овој елемент
• oadrResponseRequired – Контролира кога е потребен одговор за вклучување/одјавување. Може да биде секогаш или никогаш
• oadrSampСтапка на линг - Sampстапка на линг за податоци од типот на телеметрија
• oadrService –
• oadrServiceName – Овој тип на цел се користи за настани, извештаи и распореди за избор. Вредноста вообичаено би ја доделила услужната компанија за време на запишувањето во програма за ДР
• oadrServiceSpecificInfo – Информации за регистрација на одредена услуга
• oadrSetPoint –
• oadrSignedObject –
• oadrТранспорт – Име за транспорт поддржано од VEN или VTN
• oadrTransportAdress – Root адреса што се користи за комуникација со друга страна. Доколку е потребно, треба да вклучи порта
• oadrTransportName – Името за транспорт на OpenADR, како што е simpleHttp или xmpp
• oadrТранспорт - OpenADR транспорти поддржани со имплементација
• oadrUpdatedReport - Потврдете го приемот на извештајот
• oadrUpdateReport – Испратете претходно побаран извештај
• oadrВредност –
• oadrVenName - VEN име. Може да се користи во VTN GUI
• oadrXmlПотпис - Имплементацијата поддржува XML потпис
• optID - Идентификатор за интеракција на избор
• optReason - Набројана вредност за оптималната причина како што е x-распоред
• optType - optIn или optOut од настан, или се користи за означување на типот на распоред за откажување дефиниран во vavailablityObject за услугата EiOpt
• ID на партијата – Овој тип на цел се користи за настани, извештаи и распореди за избор. Вредноста вообичаено би ја доделила услужната компанија за време на запишувањето во програма за ДР
• payloadFloat - Вредност на податочна точка за сигнали за настани или за известување тековни или историски вредности.
• пнод - Ценовниот јазол е директно поврзан со јазол за поврзување. Тоа е локација за цените за која учесниците на пазарот ги поднесуваат своите понуди, понуди, купуваат/продаваат CRR и решаваат.
• точкаНа Испорака –
• точка на прием –
• Послиста –
• моќно очигледно - Очигледна моќност мерена во волти-ampерес (VA)
• моќАтрибути
• powerItem
• powerReactive - Реактивна моќност, мерена во волти-ampереактивен (VAR)
• моќно Реално - Реална моќност измерена во вати (W) или џули/секунда (J/s)
• приоритет - Приоритетот на настанот во однос на другите настани (Колку е помал бројот, поголем е приоритетот. Вредноста од нула (0) покажува без приоритет, што е стандардно најнискиот приоритет).
• својства –
• Број на пулс – Точка со податоци за известување
• пулсен фактор - kWh по број
• квалификуван ИД на настан – Уникатна лична карта за настан
• Тип на читање - Метаподатоци за читањата, како што се средни или изведени
• ID на регистрација - Идентификатор за трансакција за регистрација. Не е вклучено како одговор на регистрација на барање, освен ако веќе не е регистриран
• replyLimit – Максималниот број на настани што треба да се вратат во товарот на oadrDistributeEvent
• извештај Назад Времетраење – Пријавете се со извештајот до датумот за секое изминување на ова времетраење.
• извештај Извор на податоци – Извори за податоци во овој извештај. Прamples вклучуваат метри или подметри. За прampЛе, ако мерачот е способен да обезбеди два различни типа на мерења, тогаш секој проток на мерење ќе биде посебно идентификуван.
• ReportInterval - Ова е целокупниот период на известување.
• Име на извештајот - Изборно име за извештај.
• ReportRequestID - Идентификатор за одредено барање за извештај
• ReportSpecifier - Наведете ги посакуваните точки на податоци во одреден пример на извештај
• ReportSpecifierID - Идентификатор за одредена спецификација на извештајот за метаподатоци
• Предмет на извештајот - Целна класа на уреди – користете само endDeviceAsset.
• извештај за следење - Покажува дали извештајот (во форма на UpdateReport) ќе се врати по откажувањето на Извештајот
• Тип на извештај – Видот на извештајот како што е употребата или цената
• ID на барање - ИД што се користи за усогласување на барање и одговор за логично трансакција
• ID на ресурс – Овој тип на цел се користи за настани, извештаи и распореди за избор. Вредноста вообичаено би ја доделила услужната компанија за време на запишувањето во програма за ДР
• одговор –
• Код на одговор - 3 цифрен код за одговор
• одговорОпис - Наративен опис на статусот на одговорот
• одговори –
• rID - ReferenceID за оваа податочна точка
• сервисна област – Овој тип на цел се користи за настани, извештаи и распореди за избор. Вредноста вообичаено би ја доделила услужната компанија за време на запишувањето во програма за ДР
• ServiceDeliveryPoint – Логичка точка на мрежата каде што сопственоста на услугата се менува. Тоа е една од потенцијално многуте услужни точки во рамките на ServiceLocation, што обезбедува услуга во согласност со Договорот за клиенти. Се користи на местото каде што може да се инсталира броило.
• локација на услугата - Локација за услуги на клиентите има една или повеќе точки за испорака на услуги, кои пак се однесуваат на метри. Локацијата може да биде точка или многуаголник, во зависност од конкретните околности. За дистрибуција, ServiceLocation е типично локацијата на просторијата на корисникот на комуналните услуги.
• ID на сигнал - единствен идентификатор за сигнал за специфичен настан
• Име на сигналот – Име на сигнал како што е SIMPLE
• signalPayload - Сигнални вредности за настани и основни линии
• siScaleCode – Фактор на скалирање за основната единица мерка за извештај
• specifierPayload – Отворено
• старт по – Прозорец за рандомизација за почеток на настанот
• статусDateTime - Датумот и времето се однесува на овој артефакт.
• температура –
• тест настан - Сè друго освен неточно укажува на тест настан
• текст –
• Термички –
• толеранција - Под-објект кој ги содржи барањата за рандомизација за настан
• толерира – Објект кој ги содржи барањата за рандомизација за настан
• транспортен интерфејс - Транспортниот интерфејс ги разграничува рабовите на двата краја на транспортниот сегмент.
• УИД - Се користи како индекс за идентификување на интервали. Единствен идентификатор
• вредност –
• достапност - Распоред кој ја одразува достапноста на уредот за учество во настани за ДР
• venID – Единствен идентификатор за VEN
• кнtage –
• vtnКоментар - Било кој текст
• vtnID – Единствен идентификатор за VTN
• x-ei Известување – VEN треба да го добие товарот на настанот DR пред dtstart минус ова времетраење.
• x-eiRampгоре - Времетраење пред или по времето на започнување на настанот во текот на кое треба да помине оптоварувањето.
• x-eiRecovery - Времетраење пред или по времето на завршување на настанот, во текот на кое треба да помине товарот.

 

Поимник на набројани вредности

настан Статус

• активни – Настанот е инициран и моментално е активен.
• откажана – Настанот е откажан.
• завршена – Настанот заврши.
• далеку – Настанот што се чека во далечна иднина. Точната дефиниција за тоа колку далеку во иднина се однесува ова зависи од пазарниот контекст, но обично значи следниот ден.
• во близина – Настанот се чека во блиска иднина. Точната дефиниција за тоа колку блиску во иднина е активен настанот што чека зависи од пазарниот контекст. .Започнува истовремено со ефективен почеток на настанот x-eiRampДополнително време. Ако x-eiRampГоре не е дефинирано за настанот, овој статус нема да се користи за настанот.
• ниеден – Ниту еден настан не чека

ставкаЕдиници

• Валута
  • американски долари – американски долари
  • За многумина да се наведат овде, погледнете ја шемата
• моќно Реално
  • J/s – Џул-секунда
  • W – Воти
• температура
  • Целзиусови –
  • Фаренхајт –

oadrDataQuality

• Нема нова вредност - користена претходна вредност –
• Без квалитет - без вредност –
• Лош квалитет - неуспех во комуникацијата –
• Лош квалитет - Грешка во конфигурацијата –
• Лош квалитет - неуспех на уредот –
• Лош квалитет - Последна позната вредност –
• Лош квалитет - неспецифичен –
• Лош квалитет - не е поврзан –
• Лош квалитет - надвор од услугата –
• Лош квалитет - Дефект на сензорот –
• Добар квалитет – Локално прескокнување –
• Добар квалитет - неспецифичен –
• Ограничување на квалитет – Поле/константа –
• Ограничување на квалитет – Поле/Висок –
• Ограничување на квалитет – Поле/ниско –
• Ограничување на квалитет – Поле/Не –
• Квалитетот е неизвесен - единиците на ЕУ се надминаа –
• Квалитет неизвесен – последна употреблива вредност –
• Квалитетот неизвесен - неспецифичен –
• Квалитетот е неизвесен - сензорот не е точен –
• Квалитетот неизвесен - Субнормално –

oadrResponseRequired

• секогаш – Секогаш испраќајте одговор за секој примен настан.
• никогаш – Никогаш не одговарајте.

optReason

Набројани причини за одлучување.

• економски –
• итен случај –
• мора да се изврши –
• не Учествуваат –
• outageRunStatus –
• замени Статуs -
• учествуваат –
• x-распоред –

oadrTransportName

• едноставен Http –
• xmpp –

OptType

• optIn – Индикација дека VEN ќе учествува на настан, или во случај на услугата EiOpt тип на распоред кој покажува дека ресурсот ќе биде достапен
• Откажите – Индикација дека VEN нема да учествува на настан, или во случај на услугата EiOpt вид распоред кој покажува дека ресурсот нема да биде достапен

Тип на читање

• Доделени – Мерачот покрива неколку [ресурси] и користењето се заклучува преку некој вид на професионално пресметување на податоци.
• Договор – Укажува дека читањето е про форма, т.е. е пријавено по договорени стапки
• Изведен – Употребата се заклучува преку познавање на времето на работа, нормалното работење итн.
• Директно читање – Читањето се чита од уред кој монотоно се зголемува, а употребата мора да се пресмета од парови на почетни и стоп читања.
• Проценето – Се користи кога отсуствува четиво во серија во која се присутни најмногу читања.
• Хибрид – Ако е збирно, се однесува на различни типови на читање во збирниот број.
• Средно – Читањето е средна вредност во периодот наведен во Грануларност
• Нето – Мерачот или [ресурсот] подготвува сопствена пресметка за вкупната употреба со текот на времето.
• Врв – Читањето е максимална (највисока) вредност во периодот означен во грануларноста. За некои мерења, може да има повеќе смисла како најниска вредност. Може да не е во согласност со збирните отчитувања. Важи само за бази на ставки со стапка на проток, т.е. Моќ, не енергија.
• Проектирано – Укажува дека читањето е во иднина и сè уште не е измерено.
• Сумирано – Неколку метри заедно обезбедуваат читање за овој [ресурс]. Ова е конкретно различно од збирното, што се однесува на повеќе [ресурси] во истиот товар. Видете исто така Хибрид.
• x-неприменливо - Не се применува
• x-RMS – Корен среден квадрат

Име на извештајот

• HISTORY_GREEN BUTTON – Извештај кој содржи податоци од зеленото копче во структурата на шемата за довод на атом
• HISTORY_USAGE – Извештај кој содржи историски податоци за користењето на енергијата
• METADATA_HISTORY_GREEN КОПЧЕ – Извештај за метаподатоци што ги дефинира можностите за известување за извештаите HISTORY_GREENBUTTON
• METADATA_HISTORY_USAGE – Извештај за метаподатоци што ги дефинира можностите за известување за извештаите HISTORY_USAGE
• METADATA_TELEMETRY_STATUS – Извештај за метаподатоци што ги дефинира можностите за известување за извештаите TELEMETRY_STATUS
• METADATA_TELEMETRY_USAGE – Извештај за метаподатоци што ги дефинира можностите за известување за извештаите TELEMETRY_USAGE
• TELEMETRY_STATUS – Извештај кој содржи информации за статусот на ресурсите во реално време, како што е состојбата на интернет
• TELEMETRY_USAGE – Извештај кој содржи информации за користење на енергија во реално време

Тип на извештај

Набројана вредност што го дава типот на извештајот што се обезбедува.

• достапен Складирање енергија – Достапен е капацитет за понатамошно складирање енергија, можеби за да се дојде до Целното складирање енергија
• avgDemand – Просечна употреба во текот на времетраењето означено со Грануларноста. Видете ја побарувачката за повеќе информации.
• Просечна употреба – Просечна употреба во текот на времетраењето означено со Грануларноста. Погледнете ја употребата за повеќе информации.
• основната линија – Може да биде побарувачка или употреба, како што е наведено од ItemBase. Покажува што би било [мерењето] ако не за настанот или регулативата. Извештајот е во формат на основна линија.
• deltaDemand – Промена на побарувачката во споредба со основната линија. Видете ја побарувачката за повеќе информации
• deltaSetPoint – Промени во зададената точка од претходниот распоред.
• deltaUsage – Промена во употребата во споредба со основната линија. Погледнете ја употребата за повеќе информации
• побарувачката – Извештајот означува количество единици (деноминирани во ItemBase или во производот EMIX). Типот на носивост е Количина. Типична ItemBase е вистинска моќ.
• отстапување – Разлика помеѓу некоја инструкција и вистинската состојба.
• Достапен е капацитетот за намалување на регулативата – Капацитетот на надолна регулација достапен за испраќање, изразен во EMIX Real Power. Товарот секогаш се изразува како позитивна количина.
• ниво - Едноставно ниво од пазарот на секој интервал.
• оперативна држава – Генерализирана состојба на ресурс како што се вклучување/исклучување, зафатеност на зграда, итн. Ниту една ItemBase не е релевантна. Потребна е екстензија за оптоварување специфична апликација.
• процентиПобарувачка – Процентtagе на побарувачката
• процентупотреба – Процентtagе на употреба
• powerFactor – Фактор на моќност за ресурсот
• цена – Цена по База на ставка на секој интервал
• читање – Извештајот покажува отчитување, како од метар. Читањата се моменти во временските промени - со текот на времето може да се пресметаат од разликата помеѓу последователните читања. Типот на носивост е пловечки
• регулатива Поставувачка точка – Зададена точка на регулатива како што е наложено како дел од регулаторните услуги
• setPoint – Извештајот ја означува сумата (деноминирана во ItemBase или во производот EMIX) моментално поставена. Може да биде потврда/враќање на контролната вредност на зададената точка испратена од VTN. Типот на носивост е Количина. Типична ItemBase е вистинска моќ.
• складиранаЕнергија – Складираната енергија се изразува како вистинска енергија, а носивоста се изразува како количина.
• targetEnergyStorage – Целната енергија се изразува како вистинска енергија, а носивоста се изразува како количина.
• Достапен е капацитетот за регулација – Достапен за испраќање капацитет за регулација нагоре, изразен во EMIX Real Power. Товарот секогаш се изразува како позитивна количина.
• употреба – Извештајот покажува количество единици (деноминирани во ItemBase или во производот EMIX) во одреден период. Типот на носивост е Количина. Типична ItemBase е RealEnergy
• x-resourceStatus – Процентtagе на побарувачката

scaleCode

• p – Пико 10**-12
• n – Нано 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_ENERGY – Ова е количината на енергија од ресурс што беше понудена во програма
• BID_LOAD – Ова е количината на оптоварување што беше понудено од ресурс во програма
• BID_PRICE – Ова е цената што ја понуди ресурсот
• CHARGE_STATE – Состојба на ресурс за складирање на енергија
• БАРАЊЕ_НАПЛАТА – Ова е цената на побарувачката
• ELECTRICITY_PRICE – Ова е цената на струјата
• ENERGY_PRICE – Ова е цената на енергијата
• LOAD_CONTROL -Поставете излез на оптоварување на релативни вредности
• LOAD_DISPATCH – Ова се користи за испраќање на товарот
• едноставно – амортизирано – за компатибилност наназад со A profile
• ЕДНОСТАВНО - Едноставни нивоа (компатибилен со OpenADR 2.0a)

Тип на сигнал

Набројана вредност што го опишува типот на сигналот како ниво или цена

• делта – Сигналот ја означува количината што треба да се промени од онаа што би се користела без сигналот.
• ниво – Сигналот означува ниво на програма.
• умножуваатr – Сигнал означува мултипликатор кој се применува на моменталната стапка на испорака или користење од она што би го користеле без сигналот.
• цена – Сигналот ја покажува цената.
• ценаПомножете сеr – Сигналот го означува мултипликаторот на цената. Проширена цена е пресметаната вредност на цената помножена со бројот на единици.
• цена Релативна – Сигналот ја означува релативната цена.
• поставена точка – Сигналот укажува на целната количина на единици.
• x-loadControlCapacity – Ова е инструкција за контролорот на оптоварување да работи на ниво кое е одреден процентtage од неговата максимална потрошувачка на носивост. Ова може да се мапира на одредени контролори на оптоварување за да се прават работи како што е возење велосипед. Забележете дека 1.0 се однесува на 100% потрошувачка. Во случај на едноставни уреди од типот ON/OFF тогаш 0 = OFF и 1 = ON.
• x-loadControlLevelOffset – Дискретни нивоа на цели броеви кои се во однос на нормалните операции каде 0 се нормални операции.
• x-loadControlPercentOffset – Процентtage промена од вообичаените операции за контрола на оптоварувањето.
• x-loadControlSetpoint – Поставки на контролорот за оптоварување.

– OpenADR A и B Profile Разлики

Единствената услуга поддржана од А проfile е услугата EiEvent. Објектот EiEvent е поедноставен во A profile со следните ограничувања:

• Дозволен е само еден сигнал по настан и тој сигнал мора да биде добро познатиот сигнал на OpenADR SIMPLE.
• Има ограничено таргетирање на настани со поддржани само venID, groupID, sourceID и 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 сега се опционални во Б проfile, вклучувајќи:

• моментална вредност

– 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). Без оглед на методот, следново fileќе бидат обезбедени (прampприкажани се):

• Корен сертификат
• Сертификат за среден корен
• Уверение за уредот
• Приватен клуч

Општо земено, Приватниот клуч се користи за шифрирање на товари испратени од VEN или VTN. Сертификатот на уредот е збир на уникатни информации за идентификација за VEN или VTN што се создадени од орган за сертификати и шифрирани со помош на Приватниот клуч. Коренот и средното files се користат за дешифрирање на сертификатот на уредот и потврдување дека сертификатот доаѓа од доверлив орган.

Во Java околина која користи JSSE, постојат две продавници за сертификати. Еден од нив се нарекува Trust Store и се користи за одржување на Root Certificate. Вториот се нарекува продавница за клучеви и се користи за складирање на синџир на сертификати кој се состои од среден сертификат за сертификати на уредот, како и приватниот клуч

Ве молиме имајте предвид дека кога користите 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 – Преземи [оптимизиран]
Водич за програма за одговор на побарувачката OpenADR 2.0 – Преземи

Референци

• Упатство за употреба