오픈ADR 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 (Critical Peak Pricing Program) 21

9.1.1 CPP DR 프로그램 특성 21

9.1.2 CPP 프로그램에 대한 OpenADR 특성 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 빠른 DR 디스패치 프로그램 특성 29

9.4.2 용량 입찰 프로그램에 대한 OpenADR 특성 31

9.5 가정용 전기차 (EV) 사용 시간 (TOU) 프로그램 33

9.5.1 주거용 EV TOU 프로그램 특성 33

9.5.2 주거용 EV TOU 프로그램을위한 OpenADR 특성 33

9.6 공공 역 전기차 (EV) 실시간 가격 프로그램 34

9.6.1 공공 역 EV RTP 프로그램 특성 34

9.6.2 공공 스테이션 EV RTP 프로그램을위한 OpenADR 특성 34

9.7 분산 에너지 자원 (DER) DR 프로그램 35

9.7.1 분산 에너지 자원 (DER) 프로그램 특성 35

9.7.2 분산 에너지 자원 (DER)에 대한 OpenADR 특성 35

부록 A – Samp파일 데이터 및 페이로드 템플릿 36

A.1 CPP (Critical Peak Pricing Program) 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 이벤트 페이로드 – 일반 B Profile 사용 사례 37

A.2 용량 입찰 프로그램 (CBP) 39

A.2.1 CBP 시나리오 1 – 단순 사용 사례, A 또는 B Profile 39

A.2.2 CBP 시나리오 2 – 일반적인 사용 사례, B profile 39

A.2.3 CBP 시나리오 3 – 복잡한 사용 사례 40

A.2.4 CBP Sample 이벤트 페이로드 – 일반 B Profile 사용 사례 40

A.3 주거용 온도 조절기 프로그램 42

A.3.1 주거용 온도 조절기 시나리오 1 – 간단한 사용 사례, A 또는 B Profile 42

A.3.2 주거용 온도 조절기 시나리오 2 – 일반적인 사용 사례, B profile 42

A.3.3 주거용 온도 조절기 시나리오 3 – 복잡한 사용 사례 43

A.3.4 주거용 온도 조절기 Sample 이벤트 페이로드 – 일반 B Profile 사용 사례 43

A.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

A.4.4 빠른 DR Sample 이벤트 페이로드 – 일반 B Profile 사용 사례 46

A.4.5 빠른 DR Sample 보고서 메타데이터 페이로드 – 일반 B Profile 사용 사례 48

A.4.6 빠른 DR Sample 보고서 요청 페이로드 – 일반 B Profile 사용 사례 48

A.4.7 빠른 DR Sample 보고서 데이터 페이로드 – 일반 B Profile 사용 사례 49

A.5 가정용 전기 자동차 (EV) 사용 시간 (TOU) 프로그램 49

A.5.1 주거용 EV 시나리오 1 – 단순 사용 사례, A 또는 B Profile 49

A.5.2 주거용 EV 시나리오 2 – 일반적인 사용 사례, B profile 50

A.5.3 주거용 EV Sample 이벤트 페이로드 – 일반 B Profile 사용 사례 50

A.6 공공 역 전기차 (EV) 실시간 가격 프로그램 53

A.6.1 공공 스테이션 EV 시나리오 1 – 일반적인 사용 사례, B profile 53

A.6.2 공공역 EV Sample 이벤트 페이로드 – 일반 B Profile 사용 사례 53

A.7 분산 에너지 자원 (DER) DR 프로그램 54

부록 B – 서비스 및 페이로드 정의 55

B.1 Open ADR은 다음 서비스를 지원합니다.

부록 C – 서비스 및 페이로드 정의 56

C.1 EiEvent 페이로드 56

C.2 EiReport 페이로드 56

C.3 EiOpt 페이로드 56

C.4 EiRegisterParty 페이로드 57

C.5 OadrPoll 페이로드 57

부록 D – 스키마 페이로드 요소 용어집 58

부록 E 열거 된 값의 용어집 65

E.1 이벤트 상태 65

E.2 항목 단위 65

E.3 oadrDataQuality 65

E.4 oadrResponse필수 66

E.5 opt이유 66

E.6 oadrTransportName 66

E.7 옵션 유형 66

E.8 읽기 유형 66

E.9 보고서이름 67

E.10 보고유형 67

E.11 스케일코드 68

E.12 신호 이름 68

E.13 신호 유형 69

부록 F – OpenADR A 및 B Profile 차이점 70

부록 G – OpenADR 보안 인증서 71

소개

이 가이드의 대상은 유틸리티와 다운 스트림 엔터티 간의 DR 이벤트 관련 메시지를 전달하기 위해 OpenADR 2.0을 사용하는 DR (수요 응답) 프로그램을 배포하려는 유틸리티와 통신 교환을 용이하게하는 장비 제조업체입니다. 독자는 수요 응답과 OpenADR 2.0 (이 시점부터는 간단히 OpenADR이라고 함)에 대한 기본적인 개념을 이해하고 있다고 가정합니다.

OpenADR 프로file 사양은 DR 이벤트 관련 정보를 교환할 때 예상되는 동작을 명확하게 정의하지만 OpenADR에는 유틸리티의 서버(VTN) 배치와 다운스트림 사이트의 클라이언트(VEN) 배치가 플러그 앤 플레이 경험이 아니라는 충분한 옵션이 있습니다. 이벤트 신호, 보고서 형식 및 타겟팅과 같은 OpenADR 특성은 DR 프로그램별로 지정해야 합니다.

표준화 된 DR 프로그램 같은 것은 없습니다. 각 DR 프로그램 디자인은 고유 한 경향이 있으며 배포 된 지역의 구조적 및 규제 요구 사항에 적합합니다. 각 DR 프로그램에는 다양한 행위자가 관련된 수많은 배포 시나리오가 있습니다.

DR 프로그램 설계, 배포 시나리오 및 OpenADR 특성의 가변성은 DR 배포 및 OpenADR 사용의 확장을 방해합니다. 이러한 변동성은 대부분 스마트 그리드의 단편적이고 복잡한 특성을 반영합니다.

유틸리티는 ex가 필요합니다.amp자체 DR 프로그램 구현을 위한 모델로 사용할 수 있도록 일반적인 DR 프로그램의 파일입니다. 장비 제조업체는 일반적인 DR 프로그램 사용 모델을 이해해야 DR 프로그램 배포 특정 기반이 아닌 개발 프로세스의 일부로 상호 운용성을 검증할 수 있습니다. 이 가이드의 목적은 다음과 같은 두 가지 목표를 모두 달성하는 것입니다.

  • 현재까지 구현 된 가장 인기있는 DR 프로그램의 공통 특성을 모델로 한 작은 표준 DR 프로그램 템플릿 세트 정의
  • 행위자와 역할을 명확하게 식별하여 실제 배포를 모델로 한 소규모 배포 시나리오를 정의합니다.
  • 각 DR 프로그램 템플릿에 특정한 OpenADR 특성에 대한 모범 사례 권장 사항 정의
  • 유틸리티가 비즈니스 요구 사항에 따라 유용한 DR 프로그램 템플릿 및 배포 시나리오를 식별하는 데 사용할 수있는 의사 결정 트리를 제공합니다.

이 가이드에서는 일반적인 DR 프로그램을 배포하는 데 필요한 대부분의 세부 정보를 해결하고이 권장 사항을 사용하여 프로그램에 배포 된 장비의 상호 운용성 테스트를 가능하게하는 명확한 권장 사항 집합을 제공하여 작업을 단순하게 유지하는 데 중점을 둡니다. 안내서.

참고문헌

  • OpenADR 프로file 사양 및 스키마 – www.openadr.org

용어 및 정의

이 문서에서는 다음 용어와 정의가 사용됩니다.

  • 수요 반응: 가격 또는 가용성 신호와 같은 공급 조건에 대응하여 고객 부하 수요를 관리하는 메커니즘
  • 집계 자 파티 – 이것은 여러 리소스를 함께 모아서 DR 프로그램의 단일 리소스로 DR 프로그램 당사자에게 제공하는 당사자입니다.
  • 애그리 게이터 중개 인프라 – 이것은 자원 및 그리드 측 엔티티 모두와 상호 작용하기 위해 Aggregator Intermediary Party가 사용하는 수요 측 인프라와는 별개의 인프라입니다.
  • 합의: 책임과 보상을 설명하는 DR 프로그램에서 역할을 수행하는 당사자 간의 계약 계약
  • 유산 – 물리적 부하의 특정 컬렉션을 나타내는 리소스 유형입니다. 자원은 자산으로 구성 될 수 있고 자산은 자원 일 수 있지만 자산은 여러 자산 또는 자원으로 더 이상 분해 될 수 없습니다.
  • 관련된: 데이터베이스 장치 구성을 통해 두 개체 간의 프로그래밍 방식 연결을 제공합니다. 예를 들어, VEN과 관련된 리소스
  • 기준선: 현장에서 조사, 검사 및 / 또는 계량을 통해 결정된대로 이벤트 전에 장비 또는 현장에서 계산 또는 측정 한 에너지 사용량 (수요).
  • 비엠에스 – 이것은 자원을 제어하는 ​​데 사용할 수있는 빌딩 관리 시스템입니다. 이를 에너지 관리 시스템이라고도합니다.
  • 복합 자원 – 이것은 각각 고유 한로드 제어 수단이있는 여러 물리적 자산의 집합 인 특수 유형의 자원입니다.
  • 고객 인센티브: DR 프로그램 참여를 위해 수요 측 자원의 소유자 / 집계 자에게 제공되는 유인.
  • 수요 측 인프라 – DR 프로그램에 등록 된 리소스를 수용하는 인프라입니다.
  • DR 로직: DR 신호를 실행 가능한 부하 제어로 변환하는 알고리즘 또는 로직. DR Logic은 여러 다른 위치에서 구현 될 수 있으며 경우에 따라 여러 하위 시스템에 분산 될 수 있습니다.
  • DR 프로그램 파티 – 이것은 그리드 인프라를 담당하고 또한 그리드 문제를 완화하는 데 사용되는 DR 프로그램을 관리하는 실체입니다. 일반적으로 유틸리티 또는 ISO입니다.
  • 등록됨: 수요 측 자원의 소유자 / 집계자는 DR 프로그램에 참여하기로 선택하고 DR 이벤트의 대상이 될 수있는 특정 자원에 대한 정보를 제공 할 수 있습니다.
  • 이벤트 활성화 기간: 부하 프로의 변화가 일어나는 동안의 기간입니다.file DR 이벤트의 일부로 요청되고 있습니다.
  • 이벤트 제약: 고객이 주말 또는 연속 된 날에 이벤트 없음과 같은 이벤트 및 관련 제약을받을 것으로 예상 할 수있는 기간
  • 이벤트 일: DR 이벤트가 발생하는 날입니다. 대부분의 프로그램에는 주어진 달력 기간에 허용되는 이벤트 날짜 수에 제한이 있습니다.
  • 이벤트 설명자: 프로그램 이름 및 이벤트 우선 순위와 같은 이벤트에 대한 메타 데이터를 설명하는 OpenADR 이벤트 개체의 일부
  • 이벤트 기간: 이벤트의 길이. 대부분의 프로그램은 이벤트의 길이와 이벤트가 발생할 수있는 시간에 대한 제한을 정의합니다.
  • 이벤트 신호: 전기 요금이나 특정 수준의 부하 차단과 같은 이벤트에 포함 된 실행 가능한 정보는 일반적으로 이벤트 수신자가 미리 프로그래밍 된 부하 차단 동작을 트리거하도록 요청했습니다. DR 프로그램 정의는 사용되는 이벤트 신호 유형을 지정해야합니다.
  • 이벤트 타겟팅: DR 이벤트의 수신자 인로드 차단 리소스입니다. 이는 지리적 영역, 특정 장치 클래스, 그룹 식별자, 리소스 ID 또는 기타 식별자 일 수 있습니다. DR 프로그램 정의는 특정 자원이 대상이되는 방법을 지정해야합니다.
  • 이벤트: 이벤트는 특정 시간에 지정된 기간 동안 부하 차단을 요청하는 수요 측 자원을 요구하는 유틸리티의 알림이며 이벤트에 참여해야하는 특정 자원을 지정하는 타겟팅 정보를 포함 할 수 있습니다.
  • 진행자 중개 인프라 – 이것은 자원 및 그리드 측 엔티티 모두와 상호 작용하기 위해 촉진자 중개자가 사용하는 수요 측 인프라와는 별도의 인프라입니다.
  • 진행자: 유틸리티를 대신하여 DR 프로그램 실행의 일부 또는 전체를 관리하는 제 XNUMX 자
  • 그리드 인프라 – 이것은 DR 프로그램 당사자가 소유하거나 관리하는 인프라입니다. 이 인프라에는 DR 프로그램에 등록 된 리소스에 DR 신호를 보내는 데 사용되는 OpenADR VTN 구현이 포함됩니다.
  • 중개자 – 일반적으로 자원 당사자를 대신하여 DR 프로그램 참여를 촉진하는 당사자입니다.
  • 부하 제어 – 실제로 Resource를 제어하고 특정 Load Pro를 생성하는 Resource와 관련된 인프라입니다.file.
  • 로드 프로file 목적: DR 프로그램을 개발하고 이벤트를 발행하는 동기. 최대 부하를 줄이고 자하는 욕구 등.
  • 공고: 수요 측 자원 소유자가 보류중인 이벤트에 대해 알림을받는 이벤트 시작 시간 전의 시간
  • 옵트 동작: 이벤트 수신시 수요 측 자원 소유자의 예상 응답입니다. 이 응답은 자원이 이벤트에 참여할 것인지 여부와 OptIn 또는 OptOut 표시 형식을 취할 수 있습니다.
  • 옵트 응답: 특정 프로그램이 이벤트에 대한 응답으로 수요 측 자원의 응답을 요구해야하는지 여부 및 해당 응답이 일반적으로 무엇인지.
  • 옵트 서비스: 이벤트에 참여하기위한 리소스 가용성의 일시적인 변경을 나타 내기 위해 OpenADR을 통해 통신 된 일정입니다.
  • 필수 조건: 수요 측 자원 소유자가 DR 프로그램에 등록하기 위해 충족해야하는 기준입니다. 여기에는 간격 회의의 가용성 또는 일부 최소 부하 차단 용량이 포함될 수 있습니다.
  • 주요 동인: DR 프로그램을 생성하고 이벤트를 발행하기위한 유틸리티 부분의 주요 동기. "최대 수요 감소 및 자원 적절성"
  • 프로그램 – 리소스가 등록 된 DR 프로그램입니다.
  • 프로그램 설명: 프로그램 작동 방식에 대한 설명입니다. 이 문서에 정의 된 DR 프로그램 템플릿의 일부
  • 프로그램 시간 프레임: DR 프로그램이있는 기간 또는 계절은 일반적으로 활성화됩니다.
  • 요금 설계: 수요 측 자원 소유자가 프로그램에 참여하도록 동기를 부여하기 위해 지불하는 요율 구조 또는 인센티브에 대한 특정 수정
  • 등록 서비스: OpenADR 프로토콜에서 VTN과 VEN 간의 기본 상호 운용성을 설정하고 VEN이 유틸리티 고객 계정과 연결되어 있는지 확인하기 위해 사용하는 서비스입니다.
  • 보고 서비스: VEN이 VEN에보고를 제공 할 수 있도록 OpenADR에서 사용하는 서비스입니다. DR 프로그램은 프로그램에 대한보고 요구 사항을 지정해야합니다.
  • 리소스 파티 – DR 프로그램에 등록 할 수있는 수요 측 리소스를 소유하는 당사자입니다.
  • 의지 – 이것은 DR 프로그램에 등록되어 로드 프로에 일종의 변경 사항을 전달할 수 있는 엔터티입니다.file VTN으로부터 DR 신호 수신에 대한 응답으로.
  • 대상 고객: 프로file 주거, 산업 또는 전기 소비 수준을 기반으로 하는 특정 DR 프로그램에 등록할 수 있는 수요측 자원의
  • 목표 부하: 수신시 부하를 수정해야하는 수요 측 리소스
  • – 이것은 VTN과 상호 작용하는 데 사용되는 OpenADR 가상 끝 노드입니다.
  • 비티엔 – DR 프로그램에 등록 된 리소스와 상호 작용하는 데 사용되는 OpenADR 가상 최상위 노드입니다.

약어

  • 비엠에스: 빌딩 관리 시스템
  • C & I: 상업 및 산업
  • 통신: 두 엔티티 간의 통신
  • DR: 수요 대응
  • 응급의료: 에너지 관리 시스템
  • 오픈ADR: 개방형 자동 수요 응답
  • 프로그램: 수요 응답 프로그램에 대한 참조
  • : 가상 엔드 노드
  • 비티엔: 가상 최상위 노드

수요 응답 프로그램 유형

이 문서에는 아래 표시된 DR 프로그램에 대한 템플릿이 포함되어 있습니다.

 

1. 중요한 최고 가격: 제한된 일 또는 시간 동안 미리 지정된 높은 요율 또는 가격을 부과함으로써 높은 도매 시장 가격 또는 시스템 우발적 인 기간 동안 소비 감소를 장려하도록 설계된 요율 및 / 또는 가격 구조.

2. 용량 입찰 프로그램: 소매 및 도매 시장의 수요 자원이 가격으로 부하 감소를 제공하거나 특정 가격에서 줄일 수있는 부하를 식별 할 수있는 프로그램입니다.

 

3. 주거용 온도 조절기 프로그램 / 직접 부하 제어: 프로그램 후원자가 갑작스럽게 고객의 전기 장비 (예 : 에어컨)를 원격 제어하는 ​​수요 대응 활동입니다. 이러한 프로그램은 주로 주거용 또는 소규모 상업 고객에게 제공됩니다.

4. 빠른 DR 파견 / 보조 서비스 프로그램: 긴급 수요 대응 이벤트 발생 시 부하 대응에 대해 고객에게 인센티브를 지급하는 수요 대응 프로그램입니다. 비정상적인 시스템 상태(예:ample, 시스템 제약 및 로컬 용량 제약) 대량 전기 시스템의 신뢰성에 부정적인 영향을 미칠 수 있는 송전 설비 또는 발전 공급의 고장을 방지하거나 제한하기 위해 자동 또는 즉각적인 수동 조치가 필요한 경우. 이러한 유형의 프로그램을 "보조 서비스"라고 하는 경우가 있습니다.

5. 전기차 (EV) DR 프로그램: 전기차 충전 비용을 수정하여 소비자의 소비 패턴을 바꾸는 수요 대응 활동.

6. DER (분산 에너지 자원) DR 프로그램: 에너지 자원을 스마트 그리드로 원활하게 통합하기 위해 활용되는 수요 대응 활동.

 

배포 시나리오

DR 프로그램이 배포되는 방식은 DR 프로그램 자체의 특성과 다소 독립적입니다. 다음 다이어그램은 DR 프로그램을 배포 할 수있는 다양한 방법을 보여줍니다. 다음 섹션에서는 배포 시나리오와 가장 많이 사용되는 DR 프로그램 간의 상호 참조를 제공합니다.

이 섹션의 다이어그램은 다양한 시나리오에서 엔터티 간의 관계를 보여줍니다.

직접 1

다이렉트_1.jpg

이것은 DR 프로그램 당사자와 리소스 당사자 간에 직접적인 관계가 있는 간단한 시나리오입니다. 리소스 당사자는 자체 리소스를 DR 프로그램에 등록할 책임이 있으며 그리드 인프라는 수요측 인프라 내에 있는 VEN을 통해 리소스와 직접 상호 작용합니다. 또한 VEN은 자원 당사자가 소유하며 자원 및 해당 컨트롤러와 분리됩니다. VEN이 DR 신호를 수신하면 일반적으로 부하 제어 로직을 구현하지 않고 적절한 조치를 취하는 부하 컨트롤러에 신호를 전달합니다. 전amp이 시나리오의 파일에는 OpenADR VEN이 포함된 게이트웨이를 설치할 수 있는 C&I 건물이 포함되며 해당 게이트웨이에서 신호를 수신하면 이를 단순히 다른 프로토콜로 변환하고 부하 컨트롤러 자체에 전달합니다.

직접 2

다이렉트_2.jpg

이것은 Direct 1 시나리오와 매우 유사합니다. 주요 차이점은 VEN이 인스턴스화되는 방식과 VTN과의 상호 작용이 촉진된다는 것입니다. VEN은 DR 로직을 구현하고 더 중앙 집중식 위치에서 복합 리소스 및 다양한 부하 컨트롤러와 상호 작용할 수 있는 중앙 집중식 BMS와 같은 엔터티에서 인스턴스화됩니다. 전amp파일에는 건물의 다양한 부하(예: 조명, HVAC, 산업 공정 등)를 제어하는 ​​BMS가 있는 대형 건물이 포함됩니다.amp중앙 집중식 제어 시스템이 있는 여러 시설을 사용할 수 있습니다.

직접 3

다이렉트_3.jpg

이 시나리오는 Direct 1 시나리오와 매우 유사합니다. 주요 차이점은 VEN이 리소스와 부하 컨트롤러에서 직접 인스턴스화된다는 것입니다. 이 경우 DR 신호는 리소스와 해당 부하 컨트롤러로 직접 전송됩니다. 소위 "장치 가격" 시나리오가 이 범주에 속합니다. 전amp파일에는 그리드 측 엔티티 VTN과 직접 상호 작용할 수 있는 내장 VEN이 있는 HVAC(즉, 온도 조절기)와 같은 모든 종류의 부하 컨트롤러가 포함됩니다.

직접 4

다이렉트_4.jpg

이것은 일종의 Direct 1 및 Direct 2 시나리오의 조합입니다. 주요 차이점은 여러 VEN이 자체 로드 컨트롤러가 있는 여러 자산으로 구성된 단일 복합 리소스와 연결된다는 것입니다. 복합 자원을 구성하는 각각의 로드 컨트롤러는 다른 VEN과 연관될 수 있습니다. 모든 VEN은 복합 자원을 소유하는 동일한 자원 당사자의 통제 하에 있음을 유의하십시오. 이 시나리오는 복합 자원이 있지만 Direct 2 시나리오와 같은 중앙 집중식 BMS가 없는 수요측 인프라를 용이하게 하기 위해 존재합니다. 전amp파일에는 각 층에 다른 부하 컨트롤러가 있지만 중앙 집중식 BMS가 없는 건물이 포함될 수 있습니다. 또는 camp각 건물의 다른 컨트롤러와 함께 사용하지만 c는 사용하지 않음amp우리 와이드 컨트롤러. DR 프로그램 당사자의 관점에서 프로그램에 등록된 단일 리소스만 있기 때문에 리소스에 DR 신호를 보내려고 할 때 리소스와 연결된 각각의 지정된 VEN에 동일한 신호를 단순히 보낼 수 있습니다.

진행자 1

진행자_1.jpg

이 시나리오에는 DR 프로그램 당사자와 자원 간의 상호 작용을 촉진하는 중개자가 있습니다. 일반적으로 중개 당사자는 자원 당사자를 대신하여 자원 관리를 돕습니다. 리소스 당사자는 DR 프로그램 당사자와 직접적인 관계가 있으며 자신의 리소스를 DR 프로그램에 등록합니다. 따라서 DR 프로그램 당사자는 view■ 각 리소스 당사자는 별도의 리소스로 간주되며 개별적으로 상호 작용할 수 있습니다. 중개 당사자의 역할은 모든 OpenADR 관련 상호 작용을 위한 중간 역할을 하는 것이므로 VEN은 촉진자 중개 인프라 내에서 인스턴스화됩니다. 이러한 인프라는 클라우드 기반인 경우가 많으며 리소스 당사자에게 SaaS(Software as a Service)로 제공됩니다. DR 신호가 퍼실리테이터의 VEN에 의해 ​​수신되면 DR 신호를 적절한 리소스로 전달하고 어떤 종류의 DR 로직을 구현하고 각 리소스의 부하 컨트롤러에 부하 제어 명령을 전송하는 것을 포함하여 다양한 작업이 발생할 수 있습니다. 전amp이 시나리오의 파일은 다음과 같습니다.

  • 대형 소매 업체와 같은 대형 상업 체인의 시설을 관리하는 공급 업체.
  • 산업 제어 중개자.
  • 에너지 서비스 회사 (ESCO)
  • 새로운 스마트 통신 온도 조절기 공급 업체와 같은 클라우드 기반 기기 및 장치 관리 시스템.

애그리 게이터 1

애그리게이터_1.jpg

이 시나리오는 진행자 시나리오와 유사합니다. 주요 차이점은 집계 당사자가 리소스 당사자와 달리 DR 프로그램 당사자와 관계가 있다는 것입니다. 집계 당사자는 여러 고객 자산을 DR 프로그램에 등록하는 단일 리소스로 집계합니다. DR 프로그램 당사자는 Aggregator가 관리하는 개별 자산에 대한 가시성이 없습니다. Facilitator와 마찬가지로 Aggregator에는 VEN이 인스턴스화되는 자체 인프라가 있습니다. 차이점은 DR 신호가 수신 될 때 단일 리소스를 참조하고 Aggregator는 DR 신호에 지정된 목표를 달성하기 위해 포트폴리오의 모든 자산에 대해 일종의 DR 로직을 구현한다는 것입니다.

 

배포 시나리오 및 DR 프로그램 매핑

아래 표에는 특정 DR 프로그램에 가장 일반적인 배포 시나리오가 나와 있습니다.

배포 시나리오
DR 템플릿 직접 1, 2, 3, 4 진행자 1 애그리 게이터 1
CPP 프로그램
용량 입찰 프로그램
주거용 온도 조절기

프로그램

빠른 DR 파견
전기차 (EV) DR 프로그램
DER (분산 에너지 자원) DR 프로그램

DR 프로그램 템플릿 선택

다음은 새로운 DR 프로그램을 구현하려는 유틸리티와 관련된 일련의 질문입니다. 이것은 포괄적 인 의미는 아니지만 좀 더 적절한 문제를 나타냅니다. 이러한 질문의 목적은 유틸리티를 적절한 DR 프로그램 템플릿 세트로 안내하는 데 도움이됩니다.

Q : DR을 수행하려는 이유는 무엇입니까? DR로 완화하려는 그리드 상태 또는 운영 문제는 무엇입니까?

이것은 지금까지 가장 중요한 질문이며 DR 프로그램이 달성해야 하는 것에 대한 전체 요구 사항 및 목표의 기초를 형성합니다. 이 질문에 대한 대답은 수요 측이 프로를 로드하는 방법을 정의합니다.file DR 프로그램에 의해 형성되어야 합니다. 다른 모든 요구 사항은 이 질문에 대한 답변에서 비롯됩니다.

  • 봉우리를 면도하려고하십니까?
  • 오리 배를 채우시겠습니까?
  • 전기의 현물 가격을 헤지하려고합니까?
  • 그리드 안정성에 관심이 있습니까?
  • 그리드 자산을 보존하려고합니까?
  • 기타 등등.

아래 표는 DR 프로그램을 개발하려는 동기에 대한 몇 가지 추가 컨텍스트를 제공합니다.

그리드 신뢰성 및 안전성 주파수 및 볼륨tage 안정성
자원 적절성
최대 용량
Ramp잉
우연성
에너지 조달 현물 시장 가격
가격 차익 거래
자산 관리 손상 방지
유지관리 감소
평생 연장
용량 관리 경제적 혜택
비상 관리
환경 네가 와트
깨끗한 에너지

Q :이 프로그램에 대한 기존 DR 프로그램이나 요금이 이미 적용되어 있습니까?

  • 종종 프로그램 규칙은 관세에 명시 적으로 설명되어 있습니다.

Q :이 프로그램으로 어떤 수요 측 시장을 목표로 삼고 있습니까?

이것은 이벤트에서 자원의 대상과 신호 유형을 결정하는 데 도움이 될 수 있습니다.

  • 주거용
  • 대규모 C & I
  • 소규모 C & I
  • 농업
  • 물 관리
  • 전기 자동차
  • 등등, 등등, 등등

Q : 특정 유형의로드를 목표로하고 있습니까?

  • 온도 조절 장치
  • 전기 자동차
  • Ag 펌프
  • 등.

Q : 배포 모델은 무엇입니까?

이 질문에 대한 답은 프로그램 내에서 리소스가 정의되는 방식에 영향을 미치고 이러한 리소스가 이벤트 내에서 대상이되는 방식을 결정할 수 있습니다.

  • 고객에게 직접
  • 애그리 게이터 또는 촉진자와 같은 중개자를 통해
  • 고객이 자신의 VEN 장비를 조달하고 배포 할 책임이 있습니까?
  • 등.

Q : 수요 측 부하와 상호 작용하려는 특이성 수준은 무엇입니까?

이 질문은 배포 모델과 다소 관련이 있으며 프로그램의 리소스를 정의하고 대상을 지정하는 방법을 결정합니다. 가장 중요하고 복잡한 질문 중 하나입니다.

  • 각 개별 리소스와 상호 작용
  • 뒤에있는 리소스에 대한 사양없이 진행자 또는 애그리 게이터를 통해 상호 작용
  • 퍼실리테이터 또는 애그리 게이터를 통해 상호 작용하고 그 뒤에 어떤 리소스를 디스패치해야하는지 지정합니다.
  • 위치를 속성으로 사용하여 자원 지정
  • 일종의 유틸리티 정의 그룹화 메커니즘을 사용하여 리소스를 지정합니다.
  • 온도 조절기와 같은 개별 자산 타겟팅
  • 리소스없이 상호 작용하고 DR 이벤트 만 브로드 캐스트합니다.
  • 등.

Q: 고객 로드 프로에 영향을 미치기 위해 어떤 상호 작용 패턴을 사용하고 싶습니까?files?

이 질문은 프로그램 참가자에게 전송 될 DR 신호의 유형을 결정합니다.

  • 인센티브 (예 : 동적 가격 책정)
  • 로드 디스패치 (예 : 보조 서비스)
  • 직접 부하 제어
  • 일반 이벤트 신호
  • 등.

Q : 프로그램의 일반적인 자원 스케줄링 속성은 무엇입니까?

  • 이벤트가 호출 될 수있는 날짜 및 시간
  • 이벤트 빈도
  • 이벤트 기간
  • 이벤트 전파에 허용 가능한 대기 시간
  • 등.

Q : 프로그램의 리소스 가용성은 어떻게 결정됩니까?

  • 엄격한 프로그램 규칙에 따라
  • 자원이 수행 한 일부 지명 또는 입찰 프로세스의 일부로
  • 옵트 인 / 아웃이 허용됩니까?
  • 등.

Q : 리소스 성능에 대해 어떤 유형의 가시성이 필요합니까?

이것은 매우 광범위한 질문이며 DR 프로그램의 리소스에서 피드백되는 정보 유형을 결정합니다. 일반적으로 이것은 필요한 보고서 유형을 결정합니다.

  • 온라인 / 오프라인
  • 사용량 (현재 및 / 또는 과거)
  • 부하 응답 가능성
  • 부하 가용성
  • 로드 / 자산 상태 (현재 및 / 또는 과거)
  • 기타 등등

수요 응답 프로그램 템플릿

CPP (Critical Peak Pricing Program)

CPP DR 프로그램 특성

로드 프로file 목적 -피크 수요 감소
주요 동인 -자본 지출 감소 및 에너지 비용 감소
프로그램 설명 유틸리티가 높은 도매 시장 가격이나 전력 시스템 비상 상황을 관찰하거나 예상 할 때 지정된 기간 (예 : 더운 여름 평일 오후 3시 ~ 오후 6시) 동안 중요한 이벤트를 호출 할 수 있습니다.이 기간 동안의 전력 가격은 상당히 높습니다. 높인.
고객 인센티브 고객은 프로그램 참여에 대한 인센티브로 피크가 아닌 시간에 할인 된 에너지 가격을 제공받을 수 있습니다.
요금 설계 CPP는 에너지 소비가 극심한시기에 요금이 인상되는 가격 프로그램입니다. 일반적으로 CPP 요율은 고정, 계층 형 또는 TOU 기본 요율에 대한 가산기 또는 승수입니다.
대상 고객 -주거 또는 C & I
목표 부하 -어떤
필수 조건 -고객은 간격 측정이 있어야합니다.

-C & I 고객은 수요 기준을 충족해야 할 수 있습니다.

프로그램 시간 프레임 -일반적으로 최대 에너지 소비가 발생하는 달에 걸쳐 있지만 경우에 따라 연중 내내 발생할 수 있습니다.
이벤트 제약 -일반적으로 공휴일을 제외한 월요일 ~ 금요일, 연속적인 날 이벤트가 일반적으로 허용됨
이벤트 일 -일반적으로 연간 9-15
이벤트 기간 -일반적으로 하루 중 가장 높은 에너지 소비 시간 동안 4 ~ 6 시간 범위의 모든 이벤트에 대해 고정 된 시간 프레임 동안.
공고 -일반적으로 하루 전
옵트 동작 -일반적으로 고객은 이벤트에 참여할 필요가 없습니다.
인증

이벤트

-일반적으로 없음

CPP 프로그램에 대한 OpenADR 특성

이벤트 신호 CPP 이벤트의 가격 영향에 매핑 된 레벨 1 ~ 3의 SIMPLE 신호. CPP 프로그램에 단일 가격 구성 요소가있는 경우 수준 1에 매핑되어야합니다. 여러 가격 구성 요소가있는 CPP 프로그램의 경우 가장 작은 가격 구성 요소는 수준 1에 매핑되고 다른 가격 구성 요소는 수준 2 및 3에 증가하는 수준으로 매핑되어야합니다. 가격 영향.

- 배포가 B pro를 지원하는 경우file VEN, SIMPLE 신호 외에도 ELECTRICITY_PRICE 신호가 포함될 수 있습니다. 프로그램의 특성에 따라 priceRelative, priceAbsolute 또는 priceMultiplier 유형의 페이로드에서.

예를 들어 부록 A를 참조하십시오.amp레.

옵트 응답 -이벤트를 보내는 VTN oadrResponseRequired 요소를 "항상"으로 설정해야합니다., VEN이 optIn 또는 optOut으로 응답하도록 요구

-CPP 프로그램에 참여하는 것은 "최선의 노력"활동이므로 참여 의사의 예의 가용성 표시 이상으로 옵트 인 또는 옵트 아웃하는 공식적인 의미는 없습니다. 우리는 VEN은 고객이 취한 특정 재정의 조치가없는 한 optIn으로 응답합니다..

-oadrCreateOpt 페이로드는 일반적으로 이벤트에 참여하는 리소스를 검증하는 데 사용되지 않습니다.

이벤트 설명자 -이벤트 우선 순위는 1로 설정되어야합니다. 프로그램 규칙 또는 VTN 구성이 달리 지정하지 않는 한

테스트 이벤트는 일반적으로 사용되지 않습니다. CPP 프로그램으로. 그러나 허용되는 경우 testEvent 요소는 테스트 이벤트를 나타 내기 위해 "true"로 설정되어야합니다. 이 요소에 추가 매개 변수화 된 정보가 필요한 경우이 추가 정보와 함께 공백으로 구분 된 "true"뒤에 올 수 있습니다.

이벤트 활성화 기간 eRampUp, eiRecovery, tolerance 요소는 일반적으로 사용되지 않습니다.
기준선 기준은 일반적으로 이벤트 페이로드에 포함되지 않습니다.
이벤트 타겟팅 -CPP 프로그램은 일반적으로 특정 고객에 대한 리소스를 구분하지 않습니다. 타겟팅은 일반적으로 venID를 지정합니다., VEN과 관련된 모든 자원이 참여해야 함을 나타냅니다. 또는 모든 resourceID 목록 VEN과 관련이 있습니다.
보고 서비스 원격 분석보고는 일반적으로 사용되지 않습니다. CPP 프로그램에 꼭 필요한 것은 아니기 때문입니다.

예를 들어 부록 B를 참조하십시오.amp이 유형의 프로그램에 적용될 수 있는 유틸리티 파일럿 보고서의 파일.

옵트 서비스 Opt 서비스 사용 임시 가용성 일정을 전달하기 위해 일반적으로 사용되지 않습니다. CPP 프로그램의 일부로. 그러나 일부 배포에서는이 서비스를 사용하여 가용성 부족을 나타내는 고객을 위해 사용 가능한 이벤트 날짜를 보존 할 수 있습니다.
등록 서비스 폴링 간격 일반적인 일일 CPP 프로그램에 대해 VTN에서 요청 한 시간에 한 번 더 자주있을 필요는 없습니다. 그러나 하트 비트 감지에 폴링을 사용하려면 더 빈번한 폴링이 필요할 수 있습니다.

용량 입찰 프로그램

용량 입찰 DR 프로그램 특성

로드 프로file 목적 -최대 수요 감소 및 자원 적절성
주요 동인 -자본 지출 감소 및 에너지 비용 감소
프로그램 설명 용량 입찰 프로그램은 ISO / 유틸리티에서 애그리 게이터 또는 자체 집계 고객으로부터 사전 커밋 된 부하 차단 용량을 얻는 데 사용됩니다. 이 사전 커밋 된 부하 차단 용량은 높은 도매 시장 가격, 전력 시스템 비상 상황을 관찰하거나 예상 할 때 또는 지정된 기간 동안 DR 이벤트를 호출하여 정상적인 에너지 자원 활용의 일부로 ISO / 유틸리티에서 활용합니다.

 

일반적으로 각 집계자는이 프로그램의 일부로 수행 된 용량 약정을 충족하기 위해 자체 수요 응답 프로그램과 고객 확보 및 이벤트 알림을 설계 할 책임이 있습니다.

고객 인센티브 애그리 게이터 / 고객은 두 가지 유형의 인센티브를받습니다. 첫째, 향후 기간 동안 DR 이벤트에 사용할 수있는 특정 양의 부하 차단 용량을 보유하기위한 용량 지불을받습니다. 둘째, 미래 기간 동안 이벤트가 호출되면 이벤트 기간 동안 부하 차단에 대해 에너지를 지불 할 수 있습니다.
요금 설계 프로그램 참여자들은 미래 기간 동안 가용 한대로 보유 할 수있는 부하 차단 용량을 나타내는 "용량 추천"입찰을합니다. 입찰에는 애그리 게이터 / 고객이 기준 값 미만의 부하 차단에 대해 기꺼이 수락하려는 인센티브도 포함될 수 있습니다.

유틸리티 시장에서 용량 약정은 일반적으로 다음 달에 대한 것이지만 ISO 시장에서는 훨씬 더 긴 기간이 사용됩니다. 용량 지정의 일환으로 고객은 하루 전 또는 날짜 알림과 이벤트 기간 창 (예 : 1-4 시간, 2-6 시간,…)을 포함한 여러 특성 중에서 선택할 수 있습니다.

시간 창 동안 호출 된 이벤트가 없더라도이 사전 약정에 대해 고객에게 용량 지불이 이루어집니다. 일정 시간 동안 이벤트가 호출되면 고객은 기준선과 관련하여 부하 차단에 대한 에너지 지불을받을 수 있지만, 이벤트가 호출 될 때 전달 된 사전 커밋 된 부하 차단 용량보다 적은 경우 벌금이 적용될 수 있습니다.

대상 고객 -어 그리 게이터 및 자체 집계 C & I 고객
목표 부하 – 모두
필수 조건 -고객은 간격 측정이 있어야합니다.

-C & I 고객은 수요 또는 입찰 기준을 충족해야 할 수 있습니다.

프로그램 시간 프레임 -언제든지
이벤트 제약 -일반적으로 공휴일을 제외한 월요일 ~ 금요일, 연속적인 날 이벤트가 일반적으로 허용됨
이벤트 일 -일반적으로 한 달에 최대 30 시간
이벤트 기간 -일반적으로 하루 중 가장 높은 에너지 소비 시간 동안 모든 이벤트에 대해 고정 된 시간 창에 있습니다.). 이벤트 기간은 고객 용량 약정에 따라 다르며 선호도는 1 ~ 8 시간이거나 프로그램 설계에 따라 다릅니다.
공고 -고객 용량 약정 선호도 또는 프로그램 설계에 따라 전일 또는 당일
옵트 동작 -일반적으로 고객은 사전 커밋 된 부하 차단 용량이있는 경우 이벤트에 옵트 인합니다.
인증

이벤트

-일반적으로 XNUMX 년에 XNUMX 회 (테스트)

용량 입찰 프로그램에 대한 OpenADR 특성

이벤트 신호 부하 차단 량에 매핑 된 레벨 1 ~ 3의 SIMPLE 신호. 프로그램이 단일 수준의 부하 차단 만 지원하는 경우 이는 수준 1에 매핑되어야합니다. 여러 수준의 부하 차단이있는 프로그램의 경우 정상 작동에서 가장 작은 변화는 부하 차단 값이 매핑 된 수준 1에 매핑되어야합니다. 레벨 2 및 3은 부하 감소 정도를 증가시킵니다.

- 배포가 B pro를 지원하는 경우file VEN, SIMPLE 신호 외에도 BID_LOAD 및 / 또는 BID_PRICE 신호가 포함될 수 있습니다. setpoint 및 price의 신호 유형과 각각 powerReal 및 currencyPerKW의 단위가있는 페이로드에서. BID_LOAD는 애그리 게이터 / 고객이 용량 금액 입찰까지 요청한 부하를 반영하고 BID_PRICE는 애그리 게이터 / 고객의 인센티브 입찰을 반영합니다.

예를 들어 부록 A를 참조하십시오.amp레.

옵트 응답 -이벤트를 보내는 VTN oadrResponseRequired 요소를 "항상"으로 설정해야합니다., VEN이 optIn 또는 optOut으로 응답하도록 요구

-애그리 게이터 / 고객이 사전 커밋 된 용량을 가지고 있기 때문에 VEN은 옵트 인으로 응답해야합니다. 옵트 아웃은 이벤트에 대한 응답으로 전송 될 수 있지만 이는 공식적인 이벤트 옵트 아웃이 아니라 비공식적 인 가용성 표시입니다.

-그만큼 oadrCreateOpt 페이로드는 일반적으로 사용되지 않습니다. 일반적으로로드는 단일 집계 엔티티이므로 이벤트에 참여하는 리소스를 검증합니다.

이벤트 설명자 -이벤트 우선 순위는 1로 설정되어야합니다. 프로그램 규칙 또는 VTN 구성이 달리 지정하지 않는 한

테스트 이벤트를 사용할 수 있습니다. 용량 입찰 프로그램. 허용되는 경우 testEvent 요소는 테스트 이벤트를 나타 내기 위해 "true"로 설정되어야합니다. 이 요소에 추가 매개 변수화 된 정보가 필요한 경우이 추가 정보와 함께 공백으로 구분 된 "true"뒤에 올 수 있습니다.

이벤트 활성화 기간 eRampUp, eiRecovery, tolerance 요소는 일반적으로 사용되지 않습니다.
기준선 기준은 일반적으로 이벤트 페이로드에 포함되지 않습니다. 이 데이터는 일반적으로 이벤트가 시작될 때 사용할 수 없기 때문입니다. 그러나 유틸리티와 집계자/고객 모두 view 이벤트에 기본 정보를 포함하는 것이 유용합니다.
이벤트 타겟팅 -용량 입찰 프로그램은 일반적으로 특정 고객의 리소스를 구분하지 않습니다. 타겟팅은 일반적으로 venID를 지정합니다., VEN과 관련된 모든 자원이 참여해야 함을 나타냅니다. 또는 집계 된로드를 나타내는 resourceID를 포함합니다. VEN과 관련이 있습니다.
보고 서비스 ISO 용량 입찰 프로그램에는 일반적으로 TELEMETRY_USAGE 보고서가 필요합니다. powerReal 데이터 포인트와 함께. 전 참조amp부록 A의 les.

일반적으로 유틸리티 용량 입찰에 대한 원격 분석보고는 필요하지 않습니다..

원격 측정 보고에는 B pro가 필요합니다.file 벤.

예를 들어 부록 B를 참조하십시오.amp이 유형의 프로그램에 적용될 수 있는 유틸리티 파일럿 보고서의 파일.

옵트 서비스 Opt 서비스 사용 임시 가용성 일정을 전달하기 위해 일반적으로 사용되지 않습니다. 고객이 가용성을 미리 약속했기 때문에 용량 입찰 프로그램의 일부로. 그러나이 서비스는 참가자가 장비 고장과 같은 정상 참작 사유로 가용성 부족을 표시하는 비공식적 인 방법으로 유용 할 수 있습니다.
등록 서비스 폴링 간격 일반적인 일일 프로그램에 대해 VTN에서 요청 한 시간에 한 번 더 자주있을 필요는 없습니다. 그러나 하트 비트 감지 또는 프로그램 당일에 폴링을 사용하려면 더 빈번한 폴링이 필요할 수 있습니다.

주거용 온도 조절기 프로그램

이 프로그램은 신호 수신과 취해진 특정 부하 차단 조치 사이에 추상화 계층없이 수요 응답 신호가 부하 차단 리소스의 동작을 직접 수정하는 직접 부하 제어 (DLC)를 나타냅니다.

주거용 온도 조절기 DR 프로그램 특성

로드 프로file 목적 -피크 수요 감소
주요 동인 -자본 지출 감소 및 에너지 비용 감소
프로그램 설명 -공익 사업자들은 높은 도매 시장 가격이나 전력 시스템 비상 상황을 관찰하거나 예상 할 때 지정된 기간 (예 : 오후 3시 ~ 오후 6시) 동안 고객의 프로그래밍 가능한 통신 온도 조절기 (PCT)의 동작을 수정하는 이벤트를 시작할 수 있습니다. 여름 평일) 에너지 소비를 줄이기 위해.

-이벤트에 대한 PCT 동작의 변경은 이벤트 기간 동안 온도 설정 값의 단순한 변경이거나 사전 냉각을 포함하여 고객의 편의에 대한 이벤트의 영향을 최소화하는보다 복잡한 변경 세트 일 수 있습니다. 수평.

고객 인센티브 -인센티브는 두 가지 일반적인 형태를 취합니다. 첫째, DR 프로그램 등록에 대한 인센티브로 고객에게 무료 PCT를 제공하거나 고객이 구매 한 PCT에 대해 할인 / 리베이트를 제공 할 수 있습니다. 둘째, 고객은 프로그램에 계속 등록하면 지속적인 연봉을받을 수 있습니다. 덜 일반적인 것은 이벤트 중 실제 에너지 절감을 기반으로 고객에게 지급되는 지속적인 인센티브입니다.
요금 설계 -주로 고객이 DR 프로그램 등록에 대해 할인 또는 무료 PCT를받는 인센티브 프로그램입니다. 일부 프로그램은 이벤트 기간 동안 에너지 절감에 따라 정기적 인 급여 또는 인센티브를 지급 할 수 있습니다.

 

대상 고객 -주거
목표 부하 -공조
필수 조건 -일반적으로 없음, 고객은 프로그램 등록의 일부로 PCT를받습니다.

 

프로그램 시간 프레임 -일반적으로 최대 에너지 소비가 발생하는 달에 걸쳐 있지만 경우에 따라 연중 내내 발생할 수 있습니다.
이벤트 제약 -일반적으로 공휴일을 제외한 월요일부터 금요일까지 연속적인 날 이벤트가 일반적으로 허용됩니다.
이벤트 일 -일반적으로 연간 9-15
이벤트 기간 -이벤트는 일반적으로 하루 중 가장 높은 에너지 소비 시간에 발생하지만 2 ~ 4 시간 범위의 기간으로 언제든지 발생할 수 있습니다.
공고 -일반적으로 하루 전이지만 일부 프로그램의 경우 알림 시간이 10 분 정도로 짧을 수 있습니다.
옵트 동작 -고객은 이벤트에 참여할 필요가 없지만 이벤트를 무시하거나 이벤트 중 온도를 수동으로 조정하지 않는 한 자동으로 이벤트에 참여하게됩니다.
인증

이벤트

-일반적으로 없음

주거용 온도 조절기 프로그램을위한 OpenADR 특성

이벤트 신호 PCT 온도 설정값 오프셋 또는 자동 온도 조절 주기 비율의 변화에 ​​매핑된 레벨 1 ~ 3의 SIMPLE 신호tag전자. 주거용 온도 조절기 프로그램에 단일 오프셋 / 순환 구성 요소가있는 경우 레벨 1에 매핑되어야합니다. 여러 오프셋 / 순환 구성 요소가있는 프로그램의 경우 정상 작동에서 가장 작은 변화는 다른 오프셋 / 순환 값과 함께 수준 1에 매핑되어야합니다. 부하 차단 영향의 정도를 높이기 위해 레벨 2 및 3에 매핑되었습니다.

- 배포가 B pro를 지원하는 경우file VEN, SIMPLE 신호 외에도 LOAD_CONTROL 신호가 포함될 수 있습니다. 페이로드에서 유형의

x-loadControlLevelOffset 또는 x-loadControlCapacity 원하는 온도 설정값 오프셋 또는 자동 온도 조절 주기 비율 지정tag전자 각각. 다음을 권장합니다. x-loadControlLevelOffset signalType을 사용하는 페이로드에서 사용되는 "온도"단위 유형 오프셋에 대한 섭씨 또는 화씨를 나타냅니다.

예를 들어 부록 A를 참조하십시오.amp레.

옵트 응답 -이벤트를 보내는 VTN oadrResponseRequired 요소를 "항상"으로 설정해야합니다., VEN이 optIn 또는 optOut으로 응답하도록 요구

VEN은 고객이 취한 특정 재정의 조치가없는 한 optIn으로 응답해야합니다..

-그만큼 oadrCreateOpt 페이로드는 VEN에서 사용할 수 있습니다. 이벤트에 대한 자원 참여 자격을 부여합니다. 예를 들어 이벤트는 별도의 HVAC 시스템을 제어하는 ​​두 개의 온도 조절기의 resourceID를 대상으로 할 수 있습니다. 고객이 HVAC 시스템 중 하나만 이벤트에 참여할 수 있다고 결정하면 oadrCreateOpt 페이로드를 사용하여 VTN에 전달됩니다. oadrCreateOpt 페이로드는 B pro에서만 지원됩니다.file 벤

이벤트 설명자 -이벤트 우선 순위는 1로 설정되어야합니다. 프로그램 규칙 또는 VTN 구성이 달리 지정하지 않는 한

테스트 이벤트는 일반적으로 사용되지 않습니다. 주거용 온도 조절기 프로그램. 그러나 허용되는 경우 testEvent 요소는 테스트 이벤트를 나타 내기 위해 "true"로 설정되어야합니다. 이 요소에 추가 매개 변수화 된 정보가 필요한 경우이 추가 정보와 함께 공백으로 구분 된 "true"뒤에 올 수 있습니다.

이벤트 활성화 기간 무작위 화는 일반적으로 허용 오차 요소를 사용하는 주거용 온도 조절기 이벤트에 사용됩니다.

eRampUp 및 eiRecovery 요소는 일반적으로 사용되지 않습니다.

기준선 기준은 일반적으로 이벤트 페이로드에 포함되지 않습니다.
이벤트 타겟팅 -Residential Thermostat 프로그램은 PCT가 제어하는 ​​HVAC 자원을 대상으로합니다. 타겟팅은 일반적으로 resourceID를 지정합니다. VEN과 관련된 HVAC 시스템 (예 : 온도 조절기) 또는 이벤트 신호 장치 클래스 대상이 온도 조절기로 설정된 venID
보고 서비스 원격 분석보고는 일반적으로 사용되지 않습니다. 주거용 온도 조절기 프로그램에는 절대적으로 필요하지 않기 때문에

예를 들어 부록 B를 참조하십시오.amp이 유형의 프로그램에 적용될 수 있는 유틸리티 파일럿 보고서의 파일.

옵트 서비스 Opt 서비스 사용 임시 가용성 일정을 전달하기 위해 일반적으로 사용되지 않습니다. CPP 프로그램의 일부로.
등록 서비스 폴링 간격 VTN에서 요청한 일반적인 가정용 온도 조절기 프로그램 한 시간에 한 번 더 자주있을 필요는 없습니다. 그러나 하트 비트 감지를위한 폴링을 사용하려면 알림 시간이 상당히 짧은 주거용 온도 조절기 프로그램처럼 더 빈번한 폴링이 필요할 수 있습니다.

빠른 DR 파견

빠른 DR 디스패치 프로그램 특성

로드 프로file 목적 - "실시간"으로로드 응답을 달성하기 위해 리소스를 디스패치합니다.
주요 동인 -그리드 신뢰성 및 보조 서비스
프로그램 설명 Fast DR은 ISO / 유틸리티에서 "실시간"으로 사전 커밋 된로드 응답을 얻는 데 사용됩니다. 이 사전 커밋 된 부하 응답은 그리드의 안정성과 무결성을 유지하기 위해 즉각적인 조치가 필요한 조건을 관찰 할 때 ISO / 유틸리티에 의해 활용됩니다. 실시간이란 리소스가 일반적으로 예약으로 사용되는 리소스의 경우 10 분에서 규제 목적으로 사용되는 리소스의 경우 2 초의 지연 시간으로 발송되는 것을 의미합니다.

부하 응답의 크기는 그리드 상태를 완화하는 데 차이를 만들 수있을만큼 충분히 커야하며 따라서 리소스는 일반적으로 매우 크고 종종 집계 된 리소스의 일부로 집계자가 관리합니다. 보조 서비스에 참여할 수있는 리소스의 부하 응답에 대한 최소 크기는 일반적으로 약 500kW이지만 일부 프로그램의 경우 100kW까지 낮을 수 있습니다.

자원이 예비로 사용되는 경우 일반적으로 부하를 줄 이도록 (즉, 제거) 요청되지만, 규제 목적으로 사용되는 경우 부하를 늘리거나 줄 이도록 파견 될 수 있습니다.

고객 인센티브 애그리 게이터 / 고객은 일반적으로 두 가지 유형의 인센티브를받습니다. 첫째, 향후 기간 동안 DR 이벤트에 사용할 수있는 특정 양의로드 응답을 커밋하고 사용할 수 있도록하는 데 대한 대가를받습니다. 로드 응답 량, 가용 시간 창 및 지불 할 금액은 일반적으로 집계 자 / 고객이 설정합니다. 둘째, 미래 기간 동안 이벤트가 호출되면 이벤트 기간 동안로드 응답의 양에 따라 지불합니다.
요금 설계 프로그램 참가자는 향후 기간 동안 사용할 수있는 부하 응답을 나타내는 입찰을 제출합니다. 일반적으로 입찰에는 애그리 게이터 / 고객이로드 응답에 대해 기꺼이 수락하는 지불이 포함됩니다.

유틸리티/ISO 시장에서 입찰은 일반적으로 약정이 이루어진 날짜 전날 또는 날짜에 제출됩니다. 자격 및 시장 등록의 일부로 다양한 성능 범위 매개변수가 r과 같은 리소스와 연결됩니다.amp 속도 및 최소 및 최대 작동 제한. 이러한 매개변수는 디스패치 방법을 제어합니다.

참가자의 입찰이 수락되면 해당 기간 동안 호출된 이벤트가 없더라도 사전 약정에 대해 고객에게 지불이 이루어질 수 있습니다. 기간 동안 이벤트가 호출되는 경우 고객은 이벤트 기간 동안의 성과에 대해 추가 지불을 받을 수 있습니다. 이러한 성과 기반 지불은 에너지 양, 전력, 자원이 파견 지침을 얼마나 밀접하게 따르고 있는지, 부하가 얼마나 많은지를 반영하는 "마일리지" 지불을 포함한 여러 요인을 기반으로 할 수 있습니다.file 이벤트 기간 동안 변경이 필요했습니다. 에너지 및 전력과 같은 이러한 매개변수 중 일부는 기준선과 관련될 수 있습니다.

대상 고객 -어 그리 게이터 및 자체 집계 C & I 고객
목표 부하 – 실시간 파견에 대응할 수있는 것.
필수 조건 -고객은 간격 측정이 있어야합니다.

-부하 응답을위한 최소 크기 요구 사항을 충족해야합니다.

-실시간 파견에 대응할 수 있어야 함

-일반적으로 현재 부하 응답을 보여주는 실시간 원격 측정을 제공해야합니다.

프로그램 시간 프레임 -언제든지
이벤트 제약 -없음
이벤트 일 -없음
이벤트 기간 -일반적으로 짧지 만 (30 분 미만) 어떤 경우에도 참가자가 입찰을 제출할 때 리소스를 제공 한 시간 창을 초과하지 않습니다.
공고 -없음
옵트 동작 -고객은 사전 커밋 된로드 응답이있는 경우 기본적으로 이벤트에 옵트 인됩니다.
인증

이벤트

-일반적으로 XNUMX 년에 XNUMX 회 (테스트)

용량 입찰 프로그램에 대한 OpenADR 특성

이벤트 신호 부하 응답의 양에 매핑 된 레벨 1 ~ 3의 SIMPLE 신호. 프로그램이 단일 수준의 부하 응답 만 지원하는 경우 수준 1에 매핑되어야합니다. 여러 수준의 부하 응답이있는 프로그램의 경우 정상 작동에서 가장 작은 변화는 부하 차단 값이 매핑 된 수준 1에 매핑되어야합니다. 레벨 2 및 3의 부하 응답 수준이 증가합니다.

- 배포가 B pro를 지원하는 경우file VEN, SIMPLE 신호 외에도 LOAD_DISPATCH 신호 형태의 디스패치가 포함될 수 있습니다. 신호 유형이 설정 점 또는 델타이고 powerReal의 단위가있는 페이로드에서. 이 신호는 부하의 원하는 "작동 지점"을 나타내며 자원 현재 작동 지점에서 mW의 절대량 (즉, 설정 값) 또는 mW의 상대적인 수 (즉, 델타)로 표현할 수 있습니다.

예를 들어 부록 A를 참조하십시오.amp레.

옵트 응답 -이벤트를 보내는 VTN oadrResponseRequired 요소를 "항상"으로 설정해야합니다., VEN이 optIn 또는 optOut으로 응답하도록 요구

-애그리 게이터 / 고객이 사전 커밋 된 용량을 가지고 있기 때문에 VEN은 옵트 인으로 응답해야합니다. 옵트 아웃은 이벤트에 대한 응답으로 전송 될 수 있지만 이는 공식적인 이벤트 옵트 아웃이 아니라 비공식적 인 가용성 표시입니다.

-그만큼 oadrCreateOpt 페이로드는 일반적으로 사용되지 않습니다. 일반적으로로드는 단일 집계 엔티티이므로 이벤트에 참여하는 리소스를 검증합니다.

이벤트 설명자 -이벤트 우선 순위는 1로 설정되어야합니다. 프로그램 규칙 또는 VTN 구성이 달리 지정하지 않는 한

테스트 이벤트를 사용할 수 있습니다., 특히 자원의 등록 및 검증 중. 허용되는 경우 testEvent 요소는 테스트 이벤트를 나타 내기 위해 "true"로 설정되어야합니다. 이 요소에 추가 매개 변수화 된 정보가 필요한 경우이 추가 정보와 함께 공백으로 구분 된 "true"뒤에 올 수 있습니다.

이벤트 활성화 기간 공차 요소는 사용되지 않습니다.. 더 에이르ampUp 및 eiRecovery 기간은 일반적으로 등록할 때 리소스 매개변수의 일부이며 사용될 수 있습니다. 디스패치의 특성으로 인해 종료될 수 있으며 따라서 이벤트 종료 시간이 없을 수 있습니다.
기준선 기준은 일반적으로 이벤트 페이로드에 포함되지 않습니다. 이 데이터는 일반적으로 이벤트가 시작될 때 사용할 수 없기 때문입니다. 그러나 유틸리티와 집계자/고객 모두 view 이벤트에 기본 정보를 포함하는 것이 유용합니다.
이벤트 타겟팅 -용량 입찰 프로그램은 일반적으로 특정 고객의 리소스를 구분하지 않습니다. 타겟팅은 일반적으로 venID를 지정합니다., VEN과 관련된 모든 자원이 참여해야 함을 나타냅니다. 또는 집계 된로드를 나타내는 resourceID를 포함합니다. VEN과 관련이 있습니다.
보고 서비스 빠른 DR 프로그램에는 일반적으로 TELEMETRY_USAGE 보고서가 필요합니다. powerReal 데이터 포인트로. 사용량 보고서는 자원의 현재 작동 지점을 나타내며, 유틸리티 / ISO는 자원이 전송 된 디스패치 지시를 얼마나 가깝게 따르는 지 확인하는 데 사용됩니다.

경우에 따라 원격 측정에는 vol과 같은 다른 데이터 포인트가 포함될 수 있습니다.tag자원이 일종의 저장 형태인 경우 e 판독값 및 충전 상태(즉, 에너지). 어떤 경우에는 보고 빈도가 2초마다 높을 수 있습니다.

원격 측정 보고에는 B pro가 필요합니다.file 벤.

예를 들어 부록 A를 참조하십시오.amp레.

예를 들어 부록 B도 참조하십시오.amp이 유형의 프로그램에 적용될 수 있는 유틸리티 파일럿 보고서의 파일.

옵트 서비스 Opt 서비스를 사용하여 임시 가용성 전달 일정 일반적으로 사용되지 않습니다. 고객이 가용성을 미리 약속했기 때문입니다. 그러나이 서비스는 참가자가 장비 고장과 같은 정상 참작 사유로 가용성 부족을 표시하는 비공식적 인 방법으로 유용 할 수 있습니다.
등록 서비스 실시간 디스패치의 낮은 대기 시간 요구 사항 때문에 푸시 상호 작용 패턴 만 사용됩니다..

가정용 전기 자동차 (EV) 사용 시간 (TOU) 프로그램

주거용 전기차 TOU 프로그램 특성

로드 프로file 목적 소비자가 소비 패턴을 바꾸도록 전기 자동차 충전 비용을 수정하는 요금 구조.
주요 동인 주거 에너지 사용은 저녁에 최고조에 달합니다. EV 충전은 4 ~ 8 시간이 걸리기 때문에 부하 피크를 이동하기 위해 몇 시간 동안 지연 될 수 있습니다.
프로그램 설명 전기 자동차를 소유 한 고객은 전기 자동차 사용 시간 (EV-TOU) 요금에 가입하고 자정에서 오전 5시 사이와 같이 사용량이 적은 시간에 차량 충전에 대해 더 낮은 요금을받을 수 있습니다. EV-TOU 요금은 다음과 같습니다. 전력 수요가 가장 많은 주간 전력 사용을 제한하도록 고객에게 권장합니다.
고객 인센티브 전기차 충전 비용이 저렴합니다.
요금 설계 정오 피크, 오전 및 저녁 중간 피크, 오전 12시 ~ 오전 5시 피크가 아닌 TOU
대상 고객 로드 프로가 있는 EV 소유자file 저녁에 최고조에 달하는 것.
목표 부하 EV 충전기
필수 조건 고객은 스마트 미터와 EV를 가지고 있어야합니다.
프로그램 시간 프레임 일년 내내
이벤트 제약 없음
이벤트 일 매일 또는 평일 만
이벤트 기간 5-8시간
공고 고객은 월별 청구서의 가격 등급에 대한 알림을 받고 VTN은 이벤트 신호를 하루 전에 보냅니다.
옵트 동작 요금 납부자는 일반적으로 유틸리티에서 하듯이 요금제를 변경할 수 있습니다.
인증

이벤트

주거용 EV TOU 프로그램을위한 OpenADR 특성

이벤트 신호 실제 가격 등급이있는 ELECTRICITY_PRICE 신호와 2.0a VEN의 참여를 허용하는 SIMPLE 신호

예를 들어 부록 A를 참조하십시오.amp레.

옵트 응답 항상 VEN에 의해 ​​옵트 인
이벤트 설명자 각 가격 계층에 대한 이벤트 간격이있는 매주 하나의 이벤트
이벤트 활성화 기간 최소 24 시간 알림을 사용해야합니다. 각 이벤트 간격은 TOU 비율 계층을 캡처해야합니다.
기준선 없음
이벤트 타겟팅 고급 타겟팅은 필요하지 않으며 VEN 수준의 타겟팅 만 필요합니다.
보고 서비스 보고가 필요하지 않으며 모든 데이터는 미터에서 가져올 수 있습니다.

예를 들어 부록 B를 참조하십시오.amp이 유형의 프로그램에 적용될 수 있는 유틸리티 파일럿 보고서의 파일.

옵트 서비스 Opt 서비스는이 프로그램 유형과 관련이 없습니다.
등록 서비스 소비자는 가격 신호를 수신하기 위해 VEN에 유틸리티를 사전 프로비저닝합니다.

공공 역 전기차 (EV) 실시간 가격 프로그램

공공 역 EV RTP 프로그램 특성

로드 프로file 목적 전기 자동차 충전 비용을 수정하여 최고 가격의 현실을 소비자에게 전가시키는 수요 대응 활동.
주요 동인 전기 가격은 하루 동안 변동이 있습니다. 이 프로그램은 충전 가격을 전기 비용에보다 효율적으로 맞추는 것을 목표로합니다.
프로그램 설명 공용 충전기는 직장, 공용 주차장 및 소매점에 존재할 수 있습니다. 이 프로그램은 플러그를 꽂기 전에 잠재적 인 충전기에 실시간 가격을 전달하여 차량 충전 여부에 대해 정보에 입각 한 결정을 내릴 수 있도록합니다.
고객 인센티브 사용량이 적은 시간에 충전 비용이 저렴합니다.
요금 설계 가격은 호 변경 될 수 있습니다urly, 그러나 고객이 차량을 연결하기로 선택하면 요금이 충전 기간으로 설정됩니다.
대상 고객 집에서 멀리 떨어져있는 동안 충전해야하는 EV를 가진 사람.
목표 부하 공공 EV 충전기
필수 조건 EV 충전기는 인터넷에 연결되고 OpenADR2.0b 인증을 받거나 OpenADR2.0b VEN 게이트웨이에 연결되어야합니다.
프로그램 시간 프레임 일년 내내
이벤트 제약 없음
이벤트 일 매일 또는 평일 만
이벤트 기간 1 시간 이상
공고 고객은 차량 연결을 선택할 때 일반 요금에 대한 알림을받습니다.
옵트 동작 고객은 비용을 청구하지 않기로 결정하여 옵트 아웃 할 수 있습니다.
인증

이벤트

공공 역 EV RTP 프로그램에 대한 OpenADR 특성

이벤트 신호 ELECTRICITY_PRICE 신호로 가격이 표시됩니다.

예를 들어 부록 A를 참조하십시오.amp레.

옵트 응답 항상 VEN에 의해 ​​옵트 인
이벤트 설명자 이벤트는 연속적이어야하며 하나의 간격을 포함해야합니다.
이벤트 활성화 기간 최소 1 시간 알림을 사용해야하지만 유틸리티는 일일 알림을 사용하도록 선택할 수 있습니다.
기준선 없음
이벤트 타겟팅 고급 타겟팅이 필요하지 않지만 타겟팅을 사용하여 특정 변압기, 피더 또는 지리적 영역에 가격을 보낼 수 있습니다.
보고 서비스 보고가 필요하지 않지만 원하는 경우 사용할 수 있습니다.

예를 들어 부록 B를 참조하십시오.amp이 유형의 프로그램에 적용될 수 있는 유틸리티 파일럿 보고서의 파일.

옵트 서비스 Opt 서비스는이 프로그램 유형과 관련이 없습니다.
등록 서비스 충전소 공급 업체는 유틸리티의 VTN으로 장치를 프로비저닝합니다.

DER (분산 에너지 자원) DR 프로그램

다음 프로그램 설명은 가설이며 유틸리티 고객이 DER 스토리지 리소스를 활용하여 RTP (실시간 가격 책정) 프로그램과 같은 DR 프로그램에 참여하는 방법을 설명하는 연구 논문 (Rish의 논문 참조)을 기반으로합니다.

분산 에너지 자원 (DER) 프로그램 특성

로드 프로file 목적 분산 된 에너지 자원을 스마트 그리드에 원활하게 통합하는 데 사용되는 수요 대응 활동입니다.
주요 동인 -자본 지출 감소 및 에너지 비용 감소
프로그램 설명 에너지를 수확하고 저장할 수있는 DER 자원을 보유한 고객은 먼저 저장된 에너지 자원을 활용 한 다음 부하 차단 전략을 구현하여 높은 가격 기간 동안 그리드에서 전기 구매 비용을 최소화 할 수 있습니다.
고객 인센티브 PV 또는 기타 수단을 통해 생성 된 저장된 에너지를 활용하고 부하 차단 전략을 구현하여 높은 전기 요금이 부과되는시기에 비용을 제어 할 수있는 능력
요금 설계 전기 요금은 도매 시장 가격 또는 시간, 계절 또는 온도에 따라 달라지는 관세에 따라 다릅니다.
대상 고객 에너지 저장 자원을 보유한 고객
목표 부하 어느
필수 조건 에너지 저장 자원
프로그램 시간 프레임 언제든지
이벤트 제약 없음
이벤트 일 매일
이벤트 기간 24시간
공고 앞으로의 전진
옵트 동작 N / A – 최선의 노력 프로그램
인증

이벤트

없음

분산 에너지 자원 (DER)에 대한 OpenADR 특성

이벤트 신호 ELECTRICITY_PRICE는 24시간 동안 24시간 간격의 가격으로 XNUMX개의 신호를 보냅니다. 이 신호에는 B pro가 필요합니다.file. 이 프로그램은 A pro에 대한 SIMPLE 신호에 적합하지 않습니다.file 벤.

예를 들어 부록 A를 참조하십시오.amp레.

옵트 응답 -이벤트를 보내는 VTN oadrResponseRequired 요소를 "never"로 설정해야합니다., VEN이 응답하지 못하도록합니다.
이벤트 설명자 -이벤트 우선 순위는 1로 설정되어야합니다. 프로그램 규칙 또는 VTN 구성이 달리 지정하지 않는 한
이벤트 활성화 기간 24 시간 간격으로 1 시간, 하루 전 알림
기준선 없음
이벤트 타겟팅 venID 외에는 고급 타겟팅이 필요하지 않습니다.
보고 서비스 보고 필요 없음

예를 들어 부록 B를 참조하십시오.amp이 유형의 프로그램에 적용될 수 있는 유틸리티 파일럿 보고서의 파일.

옵트 서비스 사용하지 않음
등록 서비스 폴링 간격 VTN에서 요청한 일반적인 일일 프로그램 한 시간에 한 번 더 자주있을 필요는 없습니다. 그러나 하트 비트 감지를위한 폴링을 사용하려면 알림 시간이 상당히 짧은 주거용 온도 조절기 프로그램처럼 더 빈번한 폴링이 필요할 수 있습니다.

– 씨ample 데이터 및 페이로드 템플릿

다음 테이블 및 XML 페이로드amples는 구현자에게 실질적인 예를 제공합니다.amp이 문서의 DR 템플릿을 구현하는 방법에 대해 설명합니다. 다음 네임스페이스 접두사는 페이로드 ex에서 사용됩니다.amp레:

  • 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 (Critical Peak Pricing Program)

CPP 시나리오 1 – 단순 사용 사례, 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

  • 이벤트
    • 알림 : 이벤트 전날
    • 시작 시간 : 1pm
    • 소요시간 : 4시간
    • 무작위 화 : 없음
    • Ramp 위로: 없음
    • 회복 : 없음
    • 신호 수 : 2
    • 신호 이름 : 단순
      • 신호 유형 : 레벨
      • 단위 : 레벨 0, 1, 2, 3
      • 간격 수 1
      • 간격 기간 : 4 시간
      • 일반적인 간격 값 : 1 또는 2
      • 신호 대상 : 없음
    • 신호 이름 : ELECTRICITY_PRICE
      • 신호 유형 : 가격
      • 단위 : Kwh 당 USD
      • 간격 수 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 당 USD
      • 간격 수 3
      • 간격 기간 : 1 시간, 4 시간, 1 시간
      • 일반적인 간격 값 : $ 0.50, $ 0.75, $ 0.50 (각 간격마다)
      • 신호 대상 : 없음
    • 이벤트 대상 : Resource_1, Resource_2, Resource_3
    • 우선순위: 1
    • VEN 응답 필요 : 항상
    • VEN 예상 응답 : optIn
  • 보고서
    • 없음

CPP 에스ample 이벤트 페이로드 – 일반 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

currencyPerKWh

USD

없음

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 – 일반적인 사용 사례, B profile

  • 이벤트
    • 알림 : 이벤트 전날
    • 시작 시간 : 1pm
    • 소요시간 : 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 시간
      • 일반적인 간격 값 : 40kW, 80kW (각 간격마다)
      • 신호 대상 : 없음
    • 신호명 : BID_PRICE
      • 신호 유형 : 가격
      • 단위 : currencyPerKW
      • 간격 수 1
      • 간격 기간 : 6 시간
      • 일반적인 간격 값 : $ 3.10
      • 신호 대상 : 없음
    • 이벤트 대상 : Resource_1, Resource_2, Resource_3
    • 우선순위: 1
    • VEN 응답 필요 : 항상
    • VEN 예상 응답 : optIn
  • 보고서
    • 보고서 이름 : TELEMETRY_USAGE
    • 보고서 유형 : 사용법
    • 단위 : powerReal
    • 읽기 유형 : 직접 읽기
    • 보고 빈도 : 1 시간마다

CBP 에스ample 이벤트 페이로드 – 일반 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

W

케이

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
    • 이벤트 대상 : Resource_1
    • 우선순위: 1
    • VEN 응답 필요 : 항상
    • VEN 예상 응답 : optIn
  • 보고서
    • 없음

주거용 온도 조절기 시나리오 2 – 일반적인 사용 사례, B profile

  • 이벤트
    • 알림 : 이벤트 전날
    • 시작 시간 : 1pm
    • 소요시간 : 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, 가능한 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, 가능한 outOut (oadrCreateOpt)
  • 보고서
    • 없음

주거용 온도 조절기 Sample 이벤트 페이로드 – 일반 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

resource_1

resource_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 분
    • 시작 시간 : 1pm
    • 소요시간 : 30분
    • 무작위 화 : 없음
    • Ramp 위로: 5분
    • 회복 : 5 분
    • 신호 수 : 2
    • 신호 이름 : 단순
      • 신호 유형 : 레벨
      • 단위 : 레벨 0,1, 2, 3
      • 간격 수 1
      • 간격 시간 : 30 분
      • 일반적인 간격 값 : 1 또는 2
      • 신호 대상 : 없음
    • 신호 이름 : LOAD_DISPATCH
      • 신호 유형 : 델타
      • 단위 : powerReal
      • 간격 수 1
      • 간격 시간 : 30 분
      • 일반적인 간격 값 : 500kW ~ 2mW
      • 신호 대상 : 없음
    • 이벤트 타겟 : venID_1234
    • 우선순위: 1
    • VEN 응답 필요 : 항상
    • VEN 예상 응답 : optIn
  • 보고서
    • 보고서 이름 : TELEMETRY_USAGE
    • 보고서 유형 : 사용법
    • 단위 : powerReal
    • 읽기 유형 : 직접 읽기
    • 보고 빈도 : 1 분마다

빠른 DR 시나리오 3 – 복잡한 사용 사례

  • 이벤트
    • 알림 : 10 분
    • 시작 시간: 오후 1시
    • 소요시간 : 30분
    • 무작위 화 : 없음
    • Ramp 위로: 5분
    • 회복 : 5 분
    • 신호 수 : 2
    • 신호 이름 : 단순
      • 신호 유형 : 레벨
      • 단위 : 레벨 0,1, 2, 3)
      • 간격 수 : 2
      • 간격 소요 시간 : 15 분, 15 분
      • 일반적인 간격 값 : 1, 2 (각 간격마다)
      • 신호 대상 : 없음
    • 신호 이름 : LOAD_DISPATCH
      • 신호 유형 : 설정 점
      • 단위 : powerReal
      • 간격 수 2
      • 간격 소요 시간 : 15 분, 15 분
      • 일반적인 간격 값 : 800kW, 900kW (각 간격마다)
      • 신호 대상 : 없음
    • 이벤트 대상 : Resource_1
    • 우선순위: 1
    • VEN 응답 필요 : 항상
    • VEN 예상 응답 : optIn
  • 보고서
    • 보고서 이름 : TELEMETRY_USAGE
    • 보고서 유형 : 사용법
    • 단위: powerReal 및 voltage
    • 읽기 유형 : 직접 읽기
    • 보고 빈도 : 5 초마다

빠른 DR Sample 이벤트 페이로드 – 일반 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

W

케이

60.0

<power:voltage>220.0tage>

진실

0.0

venID_1234

항상

빠른 DR Sample 보고서 메타데이터 페이로드 – 일반 B Profile 사용 사례

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

자원 1

용법

RealEnergy

케이

직접 읽기

http : // MarketContext1

<oadr:oadrSamp링율>

PT1M

PT10M

그릇된

</oadr:oadrSamp링율>

0

ReportSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

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

ec27de207837e1048fd3

빠른 DR Sample 보고서 요청 페이로드 – 일반 B Profile 사용 사례

ReportReqID130615_192625_230

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

PT1M

PT1M

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

PT10M

rID120615_122512_981_0

x-notApplicable

VEN130615_192312_582

빠른 DR Sample 보고서 데이터 페이로드 – 일반 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

가정용 전기 자동차 (EV) 사용 시간 (TOU) 프로그램

프로그램이 상당히 구조화 된 형태로 속도 계층을 전달함에 따라 단순하고 일반적인 사용 사례 만 표시됩니다.

주거용 EV 시나리오 1 – 단순 사용 사례, A 또는 B Profile

  • 이벤트
    • 알림 : 이벤트 전날
    • 시작 시간: 오후 1시
    • 소요시간 : 24시간
    • 무작위 화 : 없음
    • Ramp 위로: 없음
    • 회복 : 없음
    • 신호 수 : 1
    • 신호명 : SIMPLE
      • 신호 유형 : 레벨
      • 단위 : N / A
      • 간격 수; 24 시간 내에 동일한 TOU 계층 변경 (2 – 6)
      • 간격 기간 : TOU 계층 활성 시간 프레임 (예 : 6 시간)
      • 일반적인 간격 값 : TOU 계층에 매핑 된 0-4
      • 신호 대상 : N / A
    • 이벤트 타겟 : venID_1234
    • 우선순위: 1
    • VEN 응답 필요 : 항상
    • VEN 예상 응답 : optIn
  • 보고서
    • 없음

주거용 EV 시나리오 2 – 일반적인 사용 사례, B profile

  • 이벤트
    • 알림 : 이벤트 전날
    • 시작 시간 : 자정
    • 소요시간 : 24시간
    • 무작위 화 : 없음
    • Ramp 위로: 없음
    • 회복 : 없음
    • 신호 수 : 2
    • 신호 이름 : 단순
      • 신호 유형 : 레벨
      • 단위 : 레벨 0, 1, 2, 3
      • 간격 수 : 24 시간 내에 동일한 TOU 계층 변경 (2 – 6)
      • 간격 기간 : TOU 계층 활성 시간 프레임 (예 : 6 시간)
      • 일반적인 간격 값 : TOU 계층에 매핑 된 0 – 4 (0 – 가장 저렴한 계층)
      • 신호 대상 : 없음
    • 신호 이름 : ELECTRICITY_PRICE
      • 신호 유형 : 가격
      • 단위 : Kwh 당 USD
      • 간격 수 : 24 시간 내에 동일한 TOU 계층 변경 (2 – 6)
      • 간격 기간 : TOU 계층 활성 시간 프레임 (예 : 6 시간)
      • 일반적인 간격 값 : $ 0.10 ~ $ 1.00 (현재 등급 요율)
      • 신호 대상 : 없음
    • 이벤트 타겟 : venID_1234
    • 우선순위: 1
    • VEN 응답 필요 : 항상
    • VEN 예상 응답 : optIn
  • 보고서
    • 없음

주거용 EV Sample 이벤트 페이로드 – 일반 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

currencyPerKWh

USD

없음

0.0

venID_1234

항상

공공 역 전기차 (EV) 실시간 가격 프로그램

이것은 실시간 가격 책정 프로그램이므로 단순하고 일반적인 사용 사례와 복잡한 사용 사례 간에 차이가 없습니다. 그러므로 samp파일 데이터는 일반적인 사용 사례에 대해서만 표시됩니다.

Public Station EV 시나리오 1 – 일반적인 사용 사례, B profile

  • 이벤트
    • 알림 : 1 시간 전
    • 시작 시간 : 1pm
    • 소요시간 : 1시간
    • 무작위 화 : 없음
    • Ramp 위로: 없음
    • 회복 : 없음
    • 신호 수 : 1
    • 신호 이름 : ELECTRICITY_PRICE
      • 신호 유형 : 가격
      • 단위 : Kwh 당 USD
      • 간격 수 1
      • 간격 기간 : 1 시간
      • 일반적인 간격 값 : $ 0.10 ~ $ 1.00
      • 신호 대상 : 없음
    • 이벤트 타겟 : venID_1234
    • 우선순위: 1
    • VEN 응답 필요 : 항상
    • VEN 예상 응답 : optIn
  • 보고서
    • 없음

공공역 EV Sample 이벤트 페이로드 – 일반 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

currencyPerKWh

USD

없음

0.0

venID_1234

항상

DER (분산 에너지 자원) DR 프로그램

이것은 실시간 가격 책정 프로그램이므로 단순하고 일반적인 사용 사례와 복잡한 사용 사례 간에 차이가 없습니다. 그러므로 samp파일 데이터는 일반적인 사용 사례에 대해서만 표시됩니다.

Public Station EV 시나리오 1 – 일반적인 사용 사례, B profile

  • 이벤트
    • 알림 : 하루 전
    • 시작 시간 : 자정
    • 소요시간 : 24시간
    • 무작위 화 : 없음
    • Ramp 위로: 없음
    • 회복 : 없음
    • 신호 수 : 24
    • 신호 이름 : ELECTRICITY_PRICE
      • 신호 유형 : 가격
      • 단위 : Kwh 당 USD
      • 간격 수 1
      • 간격 기간 : 1 시간
      • 일반적인 간격 값 : $ 0.10 ~ $ 1.00
      • 신호 대상 : 없음
    • 이벤트 타겟 : venID_1234
    • 우선순위: 1
    • VEN 응답 필요 : 없음
    • VEN 예상 응답 : n / a
  • 보고서
    • 없음

공공역 EV Sample 이벤트 페이로드 – 일반 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

currencyPerKWh

USD

없음

0.0

venID_1234

- 전amp유틸리티 파일럿의 보고서

OpenADR Alliance 회원은 다음 B Pro를 제공했습니다.file oadrUpdateReport 페이로드 sampVEN이 배치된 유틸리티 파일럿 프로그램의 파일. 다음 메모는 세 가지 페이로드와 함께 제공됩니다.amp제공되는 파일:

온도 조절기 탑재 하중 목표 :

  • 온도 조절기의 상태 (온도, 설정 점, 팬 및 모드 상태)를 알아야합니다.
  • 선택한 경우 고객이 온도 조절기 설정을 변경했는지 여부 (수동 재정의 메시지)

리베이트 페이로드 목표를위한 M & V :

  • 옵트 인의 경우 리소스 상태 및 수동 재정의
  • 총 에너지 (KWH) 및 순간 수요 (KW)에 대한 KYZ 펄스 카운터 또는 에너지 모니터의 간격 데이터

스마트 미터 / AMI 간격 데이터 페이로드 목표 :

  • AMI 검침 간격은 약 15 분에서 1 시간입니다. 유용하지만 거의 실시간 청구 추정치에 충분히 세분화되지 않음
  • 총 에너지 (KWH), 델타 에너지 (KWH), 순간 수요 (KW)

다음 네임스페이스 접두사는 페이로드 ex에서 사용됩니다.amp레:

  • 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

RUP-18

<xcal:date-time>2014-03-21T02:25:03Z</xcal:date-time>

PT1M

<xcal:date-time>2014-03-21T02:25:03Z</xcal:date-time>

PT1M

상태

진실

그릇된

0

새 값 없음 – 사용 된 이전 값

현재 온도

77.000000

새 값 없음 – 사용 된 이전 값

열 온도 설정

64.000000

새 값 없음 – 사용 된 이전 값

차가운 온도 설정

86.000000

새 값 없음 – 사용 된 이전 값

HVAC 모드 설정

3

새 값 없음 – 사용 된 이전 값

현재 HVAC 모드

0.000000

품질 없음 – 가치 없음

팬 모드 설정

2

새 값 없음 – 사용 된 이전 값

현재 홀드 모드

2

새 값 없음 – 사용 된 이전 값

현재 자리 비움 모드

0

새 값 없음 – 사용 된 이전 값

현재 습도

0.000000

품질 없음 – 가치 없음

RP21

REQ : RReq : 1395368583267

0013A20040980FAE

TELEMETRY_STATUS

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

VEN.ID:1395090780716

M&Vfor Rebates 보고서 페이로드 Sample

RUP-10

<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>

PT30S

<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>

PT30S

상태

진실

그릇된

품질 좋음 – 비 특정

펄스 수

34750.000000

품질 좋음 – 비 특정

에너지

33985.500000

품질 좋음 – 비 특정

1.26

품질 좋음 – 비 특정

RP15

REQ : RReq : 10453335019195698

0000000000522613 60

TELEMETRY_USAGE

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

VEN.ID:1439831430142

스마트 미터/AMI 간격 데이터 보고서 페이로드 Sample

RUP-4096

<xcal:date-time>2014-09-10T06:26:52Z</xcal:date-time>

PT1M

<xcal:date-time>2014-09-10T06:26:52Z</xcal:date-time>

PT15S

instantaneousDemand

6.167000

새 값 없음 – 사용 된 이전 값

intervalDataDelivered

0.051000

새 값 없음 – 사용 된 이전 값

currSumDelivered

12172.052000

새 값 없음 – 사용 된 이전 값

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

PT15S

instantaneousDemand

6.114000

새 값 없음 – 사용 된 이전 값

intervalDataDelivered

0.051000

새 값 없음 – 사용 된 이전 값

currSumDelivered

12172.052000

새 값 없음 – 사용 된 이전 값

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

PT15S

instantaneousDemand

6.113000

새 값 없음 – 사용 된 이전 값

intervalDataDelivered

0.051000

새 값 없음 – 사용 된 이전 값

currSumDelivered

12172.142000

새 값 없음 – 사용 된 이전 값

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

PT15S

instantaneousDemand

6.112000

새 값 없음 – 사용 된 이전 값

intervalDataDelivered

0.051000

새 값 없음 – 사용 된 이전 값

currSumDelivered

12172.142000

새 값 없음 – 사용 된 이전 값

RP4101

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

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

TELEMETRY_USAGE

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

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

- 서비스

Open ADR은 다음 서비스를 지원합니다.

  • EiEvent 서비스 – VTN이 VEN에 수요 응답 이벤트를 보내는 데 사용하고 VEN이 리소스가 이벤트에 참여할지 여부를 나타내는 데 사용합니다. 에이프로가 지원하는 유일한 서비스file EiEvent입니다
  • EiReport 서비스 – VEN 및 VTN이 기록, 원격 측정 및 예측 보고서를 교환하는 데 사용
  • EiOpt 서비스 – VEN에서 임시 가용성 일정을 VTN에 전달하거나 이벤트에 참여하는 리소스를 검증하는 데 사용됩니다.
  • EiRegisterParty 서비스 – VEN에 의해 ​​시작되고 VEN과 VTN 모두에서 상호 운용 가능한 페이로드 교환을 보장하는 데 필요한 정보를 교환하는 데 사용됩니다.
  • OadrPoll 서비스 – VEN이 다른 서비스의 페이로드를 위해 VTN을 폴링하는 데 사용

A와 B 프로file 서비스 작업은 모든 B pro에서 사용되는 oadrPayload 및 oadrSignedObject 래퍼를 제외하고 각 페이로드의 루트 요소에 의해 정의됩니다.file 탑재물.

– 페이로드 정의

EiEvent 페이로드

  • oadrRequest이벤트 – VTN에서 모든 관련 이벤트를 검색하기 위해 VEN이 풀 교환 모델에서 사용합니다. A pro의 기본 폴링 메커니즘으로 사용file VEN이지만 VTN과 동기화하기 위해 B VEN에서만 사용됩니다.
  • oadrDistributeEvent – VTN에서 수요 응답 이벤트를 VEN에 전달하는 데 사용
  • oadr생성된 이벤트 – VEN에서 옵트 인 또는 옵트 아웃을 통해 이벤트에 참여할지 여부를 알리는 데 사용
  • oadr응답 – VTN에서 VEN의 옵트 인 또는 옵트 아웃 수신을 확인하는 데 사용됩니다.

EiReport 페이로드

VEN과 VTN은 모두 보고서 생성자이자 보고서 요청자 모두가 될 수 있으므로 아래의 모든 페이로드는 양쪽 당사자가 시작할 수 있습니다.

  • oadr등록 보고서 – 메타 데이터 보고서에보고 기능을 게시하는 데 사용됩니다.
  • oadr등록된 보고서 -oadrRegisterReport 수신을 확인하고, 제공되는 보고서 중 하나를 선택적으로 요청합니다.
  • oadrCreateReport – VEN 또는 VTN에서 이전에 제공 한 보고서를 요청하는 데 사용됩니다.
  • oadr생성된보고서 –보고 요청 수신 확인
  • oadr업데이트보고서 -간격 데이터가 포함 된 요청 된 보고서 전달
  • oadr업데이트된 보고서 – 전달 된 보고서 수신 확인
  • oadrCancel신고 – 이전에 요청한 정기 보고서 취소
  • oadr취소 신고 – 정기 보고서 취소 확인
  • oadr응답 – 전송 계층 요청에서 애플리케이션 계층 응답이 전달 될 때 일부 풀 교환 패턴에서 자리 표시 자 응답으로 사용됩니다.

EiOpt 페이로드

  • oadrCreateOpt – 뚜렷하게 다른 두 가지 목적으로 사용
    • VEN이 DR 이벤트에 참여할 수있는 능력과 관련하여 VTN에 임시 가용성 일정을 전달하기 위해
    • VEN이 이벤트에 참여하는 자원을 자격을 갖추기 위해
  • oadrCreatedOpt – oadrCreateOpt 페이로드 수신 확인
  • oadr취소선택 -임시 예약 가능 일정 취소
  • oadr취소됨선택 – 임시 가용성 보고서 취소 확인

 

EiRegisterParty 페이로드

  • oadrQuery등록 – VEN이 실제로 등록하지 않고 VTN 등록 정보를 쿼리하는 방법.
  • oadrCreateParty등록 – VEN에서 VTN으로의 등록 요청. VEN 기능에 대한 정보를 포함합니다.
  • oadrCreatedParty등록 – oadrQueryRegistration 또는 oadrCreatePartyRegistration에 대한 응답. VEN이 상호 운용하는 데 필요한 VTN 기능 및 등록 정보를 포함합니다.
  • oadr취소파티등록 – VEN 또는 VTN에서 등록을 취소하는 데 사용
  • oadr취소된파티 등록 – oadrCancelPartyRegistration에 응답하십시오. 등록 취소 수신 확인
  • oadrRequest재등록 –이 페이로드는 풀 교환 모델의 VTN에 의해 ​​VEN에 등록 시퀀스를 다시 시작하도록 신호를 보내는 데 사용됩니다.
  • oadr응답 – 전송 계층 요청에서 애플리케이션 계층 응답이 전달 될 때 일부 풀 교환 패턴에서 자리 표시 자 응답으로 사용됩니다.

OadrPoll 페이로드

  • oadrPoll – B pro용 일반 폴링 메커니즘file 새롭거나 업데이트된 다른 서비스에 대한 페이로드를 반환합니다.
  • oadr응답 – 사용 가능한 신규 또는 업데이트 된 페이로드가 없음을 나타내는 데 사용됩니다.

– 스키마 페이로드 요소 용어집

다음은 OpenADR 2.0 페이로드에서 사용되는 스키마 요소의 알파벳순 목록입니다. 설명은 OpenADR 및 페이로드에서의 사용과 관련된 사용을 설명합니다. 요소 정의가 포함 된 페이로드 또는 사용 컨텍스트에 따라 변경 될 때 이는 설명에 기록됩니다. 루트 페이로드 정의는 부록 C에 정의되어 있으므로 제외되었습니다.

  • ac – 전력 제품이 교류인지 여부를 나타내는 부울 값
  • 정확성 – 숫자는 Interval의 페이로드 변수와 동일한 단위입니다. Confidence가있는 경우 예측의 가능한 변동성을 나타냅니다. ReadingType과 함께있는 경우 읽기 오류 가능성을 나타냅니다.
  • 집계된Pnode – 집계 된 가격 결정 노드는 시스템 영역, 기본 가격 영역, 사용자 지정 가격 영역, 제어 영역, 집계 된 생성, 집계 된 참여로드, 집계 된 비 참여로드, 거래 허브, DCA 영역과 같은 항목을 모델링하는 데 사용되는 특수한 유형의 가격 결정 노드입니다.
  • 사용 가능 – EiOpt 가용성 일정에 대한 날짜-시간 및 기간을 포함하는 개체
  • 기준 ID – 특정 기준에 대한 고유 ID
  • 기준 이름 – 베이스 라인을 설명하는 이름
  • 구성 요소
  • 신뢰 –보고 된 데이터 포인트가 정확할 통계적 확률
  • 만든 날짜 시간 – 페이로드가 생성 된 dateTime
  • 통화
  • 통화당KW
  • 통화PerKWh
  • 통화당
  • 현재의
  • 현재 값 – 현재 실행중인 이벤트 간격의 payloadFloat 값입니다.
  • 커스텀 유닛 – 사용자 정의 보고서에 대한 사용자 정의 측정 단위를 정의하는 데 사용됩니다.
  • 날짜-시간
  • dtstart – 활동, 데이터 또는 상태 변경의 시작 시간
  • 지속 – 이벤트,보고 또는 가용성 시간 간격에 대한 기간
  • 기간 – 활동, 데이터 또는 상태의 기간
  • eiActivePeriod – 전체 이벤트와 관련된 시간 프레임
  • eiCreated 이벤트 – optIn 또는 optOut을 사용하여 DR 이벤트에 응답
  • ei이벤트 -단일 이벤트에 대한 모든 정보를 포함하는 개체
  • eiEventBaseline – 비프로file
  • eiEventSignal – 이벤트의 단일 신호에 대한 모든 정보를 포함하는 개체
  • eiEventSignals – 하나 이상의 이벤트 신호 및 / 또는 기준선에 대한 간격 데이터
  • eiMarketContext – 수요 응답 프로그램을 고유하게 식별하는 URI
  • eiReportID – 보고서의 참조 ID
  • eiRequest 이벤트 – 풀 모드에서 VTN에서 이벤트 요청
  • 에이리스폰스 – 수신 된 페이로드가 허용되는지 여부 표시
  • 에이타겟 – 논리적 VEN 인터페이스와 관련된 리소스를 식별합니다. 이벤트의 경우 지정된 값이 이벤트의 대상입니다.
  • endDeviceAsset – EndDeviceAssets는 미터 또는 관심이있을 수있는 다른 유형의 장치 일 수있는 물리적 장치 또는 장치입니다.
  • 에너지명백한 – 볼트로 측정한 겉보기 에너지amp몇 시간(VAh)
  • 에너지아이템
  • 에너지 반응성 – 무효 에너지, 볼트-amp반응 시간(VARh)
  • 에너지리얼 – 실제 에너지, 와트시 (Wh)
  • 이벤트 설명자 – 이벤트에 대한 정보
  • 이벤트 ID – 특정 DR 이벤트 인스턴스를 식별하는 ID 값입니다.
  • 이벤트 응답 – 이벤트 참여 요청에 대한 VEN 응답을 포함하는 객체
  • 이벤트 응답 – 수신 된 이벤트에 대한 optIn 또는 optOut 응답
  • 이벤트 상태 – 이벤트의 현재 상태 (원거리, 근거리, 활성 등)
  • FeatureCollection / 위치 / Polygon / exterior / LinearRing
  • 빈도
  • 세분성 – 이것은 s 사이의 시간 간격입니다.amp보고서 요청에서 데이터를 주도했습니다.
  • 그룹 아이디 -이 유형의 대상은 이벤트, 보고서 및 옵트 일정에 사용됩니다. 값은 일반적으로 DR 프로그램에 등록하는 동안 유틸리티에 의해 할당됩니다.
  • 그룹 이름 –이 유형의 대상은 이벤트, 보고서 및 opt 일정에 사용됩니다. 값은 일반적으로 DR 프로그램에 등록하는 동안 유틸리티에 의해 할당됩니다.
  • 헤르츠
  • 간격 – 데이터 시간 및 / 또는 기간이 포함 된 개체, 이벤트의 경우 실행 가능한 값 또는 보고서의 경우 데이터
  • 간격 – DR 이벤트가 활성 상태이거나 보고서 데이터를 사용할 수있는 하나 이상의 시간 간격
  • 항목 설명 - 보고서 측정 단위에 대한 설명
  • 항목 단위 – 보고서 데이터 요소의 기본 측정 단위
  • 시장 컨텍스트 – DR 프로그램을 식별하는 URI
  • 미터 자산 – MeterAsset은 미터의 역할을 수행하는 물리적 장치입니다.
  • modifyDateTime – 이벤트가 수정 된 경우
  • modifyNumber – 이벤트가 수정 될 때마다 증가합니다.
  • modifyReason – 이벤트가 수정 된 이유
  • mrid – mRID는 CustomerMeter 또는 다른 유형의 EndDevice 일 수있는 물리적 장치를 식별합니다.
  • 노드 – 노드는 무언가가 변경되거나 (종종 소유권) 그리드에서 연결되는 장소입니다. 많은 노드가 미터와 연결되어 있지만 모두가 아닙니다.
  • 데이터 소스 수
  • oadr용량
  • oadr현재
  • oadrDataQuality
  • oadr장치 클래스 – 장치 클래스 대상 – endDeviceAsset 만 사용합니다.
  • oadr 이벤트 – 수요 응답 이벤트를 포함하는 객체
  • oadr 확장
  • oadrExtension 이름 –
  • oadr 확장
  • oadrHttpPull 모델 – VEN이 풀 교환 모델을 사용할 것인지 여부를 나타내는 부울
  • oadr정보 – 서비스 별 등록 정보의 키 값 쌍
  • oadrKey
  • oadr레벨오프셋
  • 로드 컨트롤 상태
  • oadr수동재정의 – 참이면 부하 제어가 수동으로 재정의되었습니다.
  • 로드맥스
  • oadrMaxPeriod – 최대 samp링 기간
  • oadrMin
  • oadrMinPeriod – 최소 초amp링 기간
  • oadr정상
  • oadrOnChange – true이면 데이터가 변경 될 때 기록되지만 minPeriod에서 지정한 빈도보다 크지 않습니다.
  • oadr온라인 – 참이면 자원 / 자산이 온라인이고 거짓이면 오프라인입니다.
  • oadr 페이로드
  • oadrPayloadResourceStatus – 현재 자원 상태 정보
  • oadr보류 중인 보고서 – 여전히 활성 상태 인 정기 보고서 목록
  • oadrPercentOffset
  • oadrProfile – 프로file VEN 또는 VTN에서 지원
  • oadrProfile이름 - OpenADR 프로file 2.0a 또는 2.0b와 같은 이름입니다.
  • oadrProfile씨 – OpenADR 프로file구현에서 지원하는
  • oadr보고 -단일 보고서에 대한 모든 정보를 포함하는 개체
  • oadr보고서설명 – 보고서 작성자가 제공 한 보고서 특성에 대한 설명. 메타 데이터 보고서에 포함
  • oadrReportOnly – ReportOnlyDevice플래그
  • oadrReport페이로드 – 보고서의 데이터 포인트 값
  • oadrRequestedOadrPollFreq – VEN은이 요소에 의해 지정된 각 기간 동안 최대 한 번 oadrPoll 페이로드를 VTN에 전송해야합니다.
  • oadrResponse필수 – optIn / optOut 응답이 필요한시기를 제어합니다. 항상 또는 절대로
  • oadrSamp링레이트 – Samp원격 분석 유형 데이터에 대한 링율
  • oadr서비스
  • oadr 서비스 이름 –이 유형의 대상은 이벤트, 보고서 및 opt 일정에 사용됩니다. 값은 일반적으로 DR 프로그램에 등록하는 동안 유틸리티에 의해 할당됩니다.
  • oadrServiceSpecificInfo – 서비스 별 등록 정보
  • oadrSetPoint
  • oadrSignedObject
  • oadr수송 – VEN 또는 VTN에서 지원하는 전송 이름
  • oadrTransport주소 – 상대방과 통신하는 데 사용되는 루트 주소입니다. 필요한 경우 포트를 포함해야합니다.
  • oadrTransportName – simpleHttp 또는 xmpp와 같은 OpenADR 전송 이름
  • oadrTransports – 구현에서 지원되는 OpenADR 전송
  • oadrUpdatedReport – 신고 접수 확인
  • oadrUpdateReport – 이전에 요청한 보고서 보내기
  • oadr값
  • oadrVen이름 – VEN 이름. VTN GUI에서 사용 가능
  • oadrXml서명 – 구현은 XML 서명을 지원합니다.
  • optID - opt 상호 작용을위한 식별자
  • 선택 이유 – x-schedule과 같은 opt 이유에 대한 열거 된 값
  • 옵션 유형 – 이벤트의 optIn 또는 optOut 또는 EiOpt 서비스에 대한 vavailablityObject에 정의 된 opt 일정 유형을 나타내는 데 사용됩니다.
  • 파티 아이디 –이 유형의 대상은 이벤트, 보고서 및 opt 일정에 사용됩니다. 값은 일반적으로 DR 프로그램에 등록하는 동안 유틸리티에 의해 할당됩니다.
  • 페이로드플로트 – 이벤트 신호 또는 현재 또는 과거 값보고를위한 데이터 포인트 값.
  • p노드 – 가격 책정 노드는 연결 노드와 직접 연결됩니다. 시장 참가자가 입찰, 제안, CRR 구매 / 판매 및 결제를 제출하는 가격 책정 위치입니다.
  • 배달 지점
  • 영수증
  • posList
  • 파워어피런트 – 볼트로 측정된 피상 전력-amp에레스(VA)
  • 전원 속성
  • 파워아이템
  • 파워리액티브 – 볼트로 측정된 무효 전력amp반응성(VAR)
  • 파워리얼 – 와트 (W) 또는 줄 / 초 (J / s)로 측정 된 실제 전력
  • 우선 순위 - 다른 이벤트와 관련된 이벤트의 우선 순위입니다. 숫자가 낮을수록 우선 순위가 높습니다. 값이 0이면 우선 순위가 없음을 나타내며 기본적으로 가장 낮은 우선 순위입니다.
  • 속성
  • 펄스 수 –보고 데이터 포인트
  • 펄스 팩터 – 카운트 당 kWh
  • QualifiedEventID – 이벤트의 고유 ID
  • 읽기 유형 – 평균 또는 파생과 같은 판독 값에 대한 메타 데이터
  • 등록ID – 등록 거래를위한 식별자. 이미 등록하지 않은 경우 쿼리 등록에 대한 응답에 포함되지 않음
  • 응답 제한 – oadrDistributeEvent 페이로드에서 리턴 할 최대 이벤트 수
  • 보고백지속시간 – 이 기간이 지나갈 때마다보고 날짜와 함께보고하십시오.
  • 보고서 데이터 소스 – 이 보고서의 데이터 소스입니다. 전amp파일에는 미터 또는 서브미터가 포함됩니다. 예를 들어ample, 미터가 두 가지 다른 유형의 측정을 제공할 수 있는 경우 각 측정 스트림은 별도로 식별됩니다.
  • 보고간격 – 이것은 전체보고 기간입니다.
  • 보고서 이름 – 보고서의 선택적 이름입니다.
  • 보고요청ID – 특정 보고서 요청에 대한 식별자
  • 보고서 지정자 – 특정 보고서 인스턴스에서 원하는 데이터 포인트 지정
  • 보고서 지정자ID – 특정 메타 데이터 보고서 사양에 대한 식별자
  • 보고서제목 – 장치 클래스 대상 – endDeviceAsset 만 사용합니다.
  • 보고하기 팔로우 – 보고서 취소 후 보고서 (UpdateReport 형식)가 반환되는지 여부를 나타냅니다.
  • 보고서 유형 – 사용량 또는 가격과 같은 보고서 유형
  • 요청ID – 논리적 트랜잭션 요청 및 응답을 일치시키는 데 사용되는 ID
  • 리소스 ID –이 유형의 대상은 이벤트, 보고서 및 opt 일정에 사용됩니다. 값은 일반적으로 DR 프로그램에 등록하는 동안 유틸리티에 의해 할당됩니다.
  • 응답
  • 응답 코드 – 3 자리 응답 코드
  • 응답 설명 – 응답 상태에 대한 설명 설명
  • 응답
  • 아이디 – 이 데이터 포인트에 대한 ReferenceID
  • 서비스 가능 지역 –이 유형의 대상은 이벤트, 보고서 및 opt 일정에 사용됩니다. 값은 일반적으로 DR 프로그램에 등록하는 동안 유틸리티에 의해 할당됩니다.
  • 서비스딜리버리포인트 – 서비스 소유권이 변경되는 네트워크의 논리적 지점입니다. ServiceLocation 내에서 잠재적으로 많은 서비스 지점 중 하나이며 CustomerAgreement에 따라 서비스를 제공합니다. 계량기를 설치할 수있는 장소에서 사용합니다.
  • 서비스위치 – 고객 ServiceLocation에는 하나 이상의 ServiceDeliveryPoint가 있으며, 이는 다시 미터와 관련됩니다. 특정 상황에 따라 위치는 점 또는 다각형이 될 수 있습니다. 배포의 경우 ServiceLocation은 일반적으로 유틸리티 고객 구내의 위치입니다.
  • 신호 ID – 특정 이벤트 신호에 대한 고유 식별자
  • 신호 이름 – SIMPLE과 같은 신호의 이름
  • 신호 페이로드 – 이벤트 및 기준선에 대한 신호 값
  • siScale코드 – 보고서의 기본 측정 단위에 대한 배율 인수
  • 지정자페이로드 – 오픈
  • 시작 후 – 이벤트 시작을위한 무작위 화 창
  • 상태 날짜 시간 – 이 아티팩트가 참조하는 날짜 및 시간입니다.
  • 온도
  • 테스트 이벤트 – false가 아닌 것은 테스트 이벤트를 나타냅니다.
  • 텍스트
  • 영국 열량 단위
  • 허용 오차 – 이벤트에 대한 무작위 화 요구 사항을 포함하는 하위 개체
  • 참다 – 이벤트에 대한 무작위 화 요구 사항을 포함하는 개체
  • 전송 인터페이스 – 전송 인터페이스는 전송 세그먼트의 양쪽 끝에있는 가장자리를 나타냅니다.
  • 아이디 – 간격을 식별하기위한 색인으로 사용됩니다. 고유 식별자
  • 가용성 – DR 이벤트 참여를위한 장치 가용성을 반영하는 일정
  • 판매점 ID – VEN의 고유 식별자
  • 권tage
  • vtn코멘트 – 모든 텍스트
  • vtnID – VTN의 고유 식별자
  • x-ei알림 – VEN은이 기간을 뺀 dtstart 전에 DR 이벤트 페이로드를 수신해야합니다.
  • x-eiRamp위로 - 부하 차단이 전달되어야하는 이벤트 시작 시간 전후의 기간입니다.
  • x-ei복구 – 부하 차단이 전달되어야하는 이벤트 종료 시간 전후의 기간입니다.

 

열거 된 값의 용어집

이벤트 상태

  • 활동적인 – 이벤트가 시작되었으며 현재 활성 상태입니다.
  • 취소 – 이벤트가 취소되었습니다.
  • 완전한 – 이벤트가 완료되었습니다.
  • 멀리 – 먼 미래에 보류중인 이벤트. 이것이 얼마나 먼 미래를 가리키는 지에 대한 정확한 정의는 시장 상황에 따라 다르지만 일반적으로 다음 날을 의미합니다.
  • 가까운 – 가까운 장래에 이벤트가 보류 중입니다. 보류 중인 이벤트가 얼마나 가까운 미래에 활성화되는지에 대한 정확한 정의는 시장 상황에 따라 다릅니다. .이벤트 x-eiR의 유효 시작과 동시에 시작amp가동 시간. 만약 x-eiRamp이벤트에 대해 작동이 정의되지 않았으므로 이 상태는 이벤트에 사용되지 않습니다.
  • 없음 – 보류중인 이벤트 없음

항목단위

  • 통화
    • 미국 달러 – 미국 달러
    • 여기에 나열 할 많은 사람들은 스키마를 참조하십시오.
  • 파워리얼
    • 조/스 – 줄초
    • W – 와트
  • 온도
    • 섭씨
    • 화씨

oadrDataQuality

  • 새 값 없음 – 이전 값이 사용됨
  • 품질 없음 – 가치 없음
  • 품질 불량 – 통신 실패
  • 품질 불량 – 구성 오류
  • 품질 불량 – 장치 오류
  • 품질 불량 – 마지막으로 알려진 값
  • 품질 불량 – 구체적이지 않음
  • 품질 불량 – 연결되지 않음
  • 품질 불량 – 서비스 중단
  • 품질 불량 – 센서 고장
  • 품질 우수 – 로컬 무시
  • 품질 우수 – 비 특정
  • 품질 제한 – 필드 / 상수
  • 품질 제한 – 필드 / 높음
  • 품질 제한 – 필드 / 낮음
  • 품질 제한 – 필드 / 아님
  • 품질 불확실 – EU 단위 초과
  • 불확실한 품질 – 마지막 사용 가능한 값
  • 불확실한 품질 – 구체적이지 않음
  • 불확실한 품질 – 센서가 정확하지 않음
  • 불확실한 품질 – 보통 이하

oadrResponse필수

  • 언제나 – 수신 된 모든 이벤트에 대해 항상 응답을 보냅니다.
  • 절대 – 응답하지 마십시오.

선택 이유

선택에 대한 열거 된 이유.

  • 간결한
  • 비상
  • 반드시 실행
  • 참여하지 않음
  • outageRun 상태
  • 재정의 상태씨 –
  • 참여하다
  • x- 스케줄

oadrTransportName

  • 단순Http
  • 엑스엠피

선택 유형

  • 옵트 – VEN이 이벤트에 참여할 것이라는 표시 또는 EiOpt 서비스의 경우 자원을 사용할 수 있음을 나타내는 일정 유형
  • 옵트 아웃 – VEN이 이벤트에 참여하지 않을 것이라는 표시 또는 EiOpt 서비스의 경우 자원을 사용할 수 없음을 나타내는 일정 유형

독서 유형

  • 할당됨 – 미터는 여러 [리소스]를 다루고 사용은 일종의 프로 데이터 계산을 통해 유추됩니다.
  • 계약 – 판독 값이 견적임을 나타냅니다. 즉, 합의 된 속도로보고됩니다.
  • 파생된 – 사용은 런타임, 정상 작동 등에 대한 지식을 통해 유추됩니다.
  • 직접 읽기 – 판독 값은 단조롭게 증가하는 장치에서 판독되며 사용량은 시작 및 중지 판독 값 쌍에서 계산되어야합니다.
  • 추정된 – 대부분의 판독 값이있는 시리즈에 판독 값이 없을 때 사용됩니다.
  • 잡종 – 집계 된 경우 집계 번호에서 다른 판독 유형을 나타냅니다.
  • 평균 – 판독 값은 Granularity에 표시된 기간 동안의 평균 값입니다.
  • 그물 – 미터 또는 [자원]은 시간 경과에 따른 총 사용량에 대한 자체 계산을 준비합니다.
  • 정점 – 판독 값은 단위로 표시된 기간 동안 최고 (최고) 값입니다. 일부 측정의 경우 가장 낮은 값으로 더 합리적 일 수 있습니다. 집계 판독 값과 일치하지 않을 수 있습니다. 유량 항목 기준 (예 : 에너지가 아닌 전력)에만 유효합니다.
  • 예상됨 – 판독 값이 미래이며 아직 측정되지 않았 음을 나타냅니다.
  • 합산 – 여러 미터가 함께이 [리소스]에 대한 판독 값을 제공합니다. 이는 특히 동일한 페이로드의 여러 [리소스]를 참조하는 집계와는 다릅니다. 하이브리드를 참조하십시오.
  • x-해당 없음 – 해당 없음
  • x-RMS – 제곱 평균 제곱근

보고서 이름

  • HISTORY_녹색버튼 – 아톰 피드 스키마 구조에 녹색 버튼 데이터가 포함 된 보고서
  • 히스토리_사용 – 과거 에너지 사용 데이터가 포함 된 보고서
  • METADATA_HISTORY_GREENBUTTON – HISTORY_GREENBUTTON 보고서에 대한보고 기능을 정의하는 메타 데이터 보고서
  • METADATA_HISTORY_USAGE – HISTORY_USAGE 보고서에 대한보고 기능을 정의하는 메타 데이터 보고서
  • METADATA_TELEMETRY_STATUS – TELEMETRY_STATUS 보고서에 대한보고 기능을 정의하는 메타 데이터 보고서
  • METADATA_TELEMETRY_USAGE – TELEMETRY_USAGE 보고서에 대한보고 기능을 정의하는 메타 데이터 보고서
  • 원격 측정_상태 – 온라인 상태와 같은 실시간 자원 상태 정보가 포함 된 보고서
  • 원격 측정_사용 – 실시간 에너지 사용량 정보가 포함 된 보고서

보고서 유형

제공되는 보고서 유형을 제공하는 열거 된 값입니다.

  • 사용 가능한 에너지 저장 – 추가 에너지 저장에 사용할 수있는 용량, 아마도 목표 에너지 저장에 도달하기 위해
  • 평균 수요 – Granularity로 표시된 기간 동안의 평균 사용량. 자세한 내용은 수요를 참조하십시오.
  • 평균 사용 – Granularity로 표시된 기간 동안의 평균 사용량. 자세한 내용은 사용법을 참조하십시오.
  • 기준선 – ItemBase에 표시된대로 수요 또는 사용량이 될 수 있습니다. 이벤트 또는 규정이 아닌 경우 [측정]이 무엇인지 나타냅니다. 보고서는 Baseline 형식입니다.
  • 델타 수요 – 기준과 비교하여 수요의 변화. 더 많은 정보에 대한 수요보기
  • 델타SetPoint – 이전 일정에서 설정 값 변경.
  • delta사용 – 기준과 비교하여 사용량의 변화. 자세한 내용은 사용법을 참조하십시오.
  • 수요 – 보고서는 단위의 양을 나타냅니다 (ItemBase 또는 EMIX 제품에 표시됨). 페이로드 유형은 수량입니다. 일반적인 ItemBase는 Real Power입니다.
  • 편차 – 일부 명령과 실제 상태의 차이.
  • 다운규제용량사용 가능 – 디스패치에 사용할 수있는 다운 레귤레이션 용량 (EMIX Real Power로 표시됨). 페이로드는 항상 양의 수량으로 표현됩니다.
  • 수준 – 각 간격에서 시장에서 간단한 수준.
  • 작동 상태 – 켜기 / 끄기, 건물 점유 등과 같은 리소스의 일반화 된 상태. ItemBase와 관련이 없습니다. 애플리케이션 별 페이로드 확장이 필요합니다.
  • 퍼센트 수요 – 퍼센tag수요의 전자
  • 백분율 사용 – 퍼센tag전자 사용
  • 역률 – 자원의 역률
  • 가격 – 각 간격에서 ItemBase 당 가격
  • 독서 – 보고서는 미터에서와 같이 판독 값을 나타냅니다. 판독 값은 시간에 따른 시간 변화의 순간이며 연속 판독 값 간의 차이에서 계산할 수 있습니다. 페이로드 유형은 부동입니다.
  • 규정 설정 점 – 규제 서비스의 일부로 지시 된 규제 설정 점
  • 세트포인트 – 보고서는 현재 설정된 금액 (ItemBase 또는 EMIX 제품에 표시)을 나타냅니다. VTN에서 보낸 설정 값 제어 값의 확인 / 반환 일 수 있습니다. 페이로드 유형은 수량입니다. 일반적인 ItemBase는 Real Power입니다.
  • 저장된 에너지 – 저장된 에너지는 실제 에너지로 표시되고 페이로드는 수량으로 표시됩니다.
  • 목표에너지저장 – Target Energy는 Real Energy로, Payload는 Quantity로 표시됩니다.
  • upRegulationCapacity사용 가능 – 디스패치에 사용할 수있는 Up Regulation 용량 (EMIX Real Power로 표시). 페이로드는 항상 양의 수량으로 표현됩니다.
  • 용법 – 보고서는 일정 기간 동안의 단위 수량 (ItemBase 또는 EMIX 제품에 표시됨)을 나타냅니다. 페이로드 유형은 수량입니다. 일반적인 ItemBase는 RealEnergy입니다.
  • x-리소스 상태 – 퍼센tag수요의 전자

스케일코드

  • p – Pico 10 **-12
  • n – 나노 10 **-9
  • 마이크로 – 마이크로 10 **-6
  • m – Milli 10 **-3
  • c – Centi 10 **-2
  • d – Deci 10 **-1
  • k – 킬로 10 ** 3
  • M – 메가 10 ** 6
  • G – Giga 10 ** 9
  • T – Tera 10 ** 12
  • 없음 – 네이티브 스케일

신호 이름

  • 입찰_에너지 – 이것은 프로그램에 입찰 된 자원의 에너지 양입니다.
  • BID_LOAD – 리소스가 프로그램에 입찰 한로드의 양입니다.
  • 입찰 가격 – 리소스가 입찰 한 가격입니다.
  • CHARGE_STATE – 에너지 저장 자원 현황
  • 수요_요금 – 이것은 수요 요금입니다
  • 전기요금_가격 – 이것은 전기 비용입니다
  • 에너지 가격 – 이것은 에너지 비용입니다.
  • 로드_컨트롤 -부하 출력을 상대 값으로 설정
  • 로드_디스패치 – 이것은 부하를 발송하는 데 사용됩니다.
  • 단순한 – 감가상각 – A pro와의 하위 호환성을 위해file
  • 단순한 – 단순 수준 (OpenADR 2.0a 준수)

신호 유형

레벨 또는 가격과 같은 신호 유형을 설명하는 열거 된 값

  • 델타 – 신호는 신호없이 사용했을 것에서 변경되는 양을 나타냅니다.
  • 수준 – 신호는 프로그램 레벨을 나타냅니다.
  • 곱하다r – 신호는 신호없이 사용했을 수있는 현재 전달 속도 또는 사용량에 적용되는 승수를 나타냅니다.
  • 가격 – 신호는 가격을 나타냅니다.
  • 가격곱하기r – 신호는 가격 승수를 나타냅니다. 확장 가격은 계산 된 가격 값에 단위 수를 곱한 값입니다.
  • 가격상대 – 신호는 상대 가격을 나타냅니다.
  • 설정 점 – 신호는 단위의 목표 양을 나타냅니다.
  • x-loadControlCapacity – 이것은 부하 컨트롤러가 몇 퍼센트 수준에서 작동하도록 지시하는 것입니다.tag최대 부하 소비 용량의 e. 이것은 특정 부하 컨트롤러에 매핑되어 듀티 사이클링과 같은 작업을 수행할 수 있습니다. 1.0은 100% 소비를 나타냅니다. 단순 ON/OFF 유형 장치의 경우 0 = OFF 및 1 = ON입니다.
  • x-loadControlLevelOffset – 0이 정상 작동 인 일반 작동에 상대적인 이산 정수 레벨.
  • x-loadControlPercentOffset – 퍼센tage 정상적인 부하 제어 작업에서 변경.
  • x-loadControlSetpoint – 컨트롤러 설정 값을로드합니다.

– OpenADR A 및 B 프로file 차이점

에이프로가 지원하는 유일한 서비스file EiEvent 서비스입니다. EiEvent 객체는 A pro에서 단순화되었습니다.file 다음과 같은 제약 조건이 있습니다.

  • 이벤트 당 하나의 신호 만 허용되며 해당 신호는 OpenADR 잘 알려진 신호 SIMPLE이어야합니다.
  • venID, groupID, resourceID 및 partyID 만 지원되는 제한된 이벤트 타겟팅이 있습니다 (eiEvent : eiTarget).
  • 기기 클래스를 사용하여 신호 수준에서 타겟팅하는 것은 지원되지 않습니다 (eiEventSignal : eiTarget : endDeviceAsset).
  • 기준선은 지원되지 않습니다 (eiEvent : eiEventSignals : eiEventBaseline).
  • modifyDateTime 및 modifyReason은 지원되지 않습니다.
  • 끝점 URL 2.0b의 간단한 HTTP는 다음과 같습니다.
    • https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

A pro에 필요한 일부 페이로드 요소file 이제 B pro에서 선택 사항입니다.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(인증서 서명 요청)을 통해 프로덕션 인증서를 요청한 결과일 수 있습니다. 방법에 관계없이 다음 files가 제공됩니다(예amp파일이 표시됨):

  • 루트 인증서
  • 중간 루트 인증서
  • 장치 인증서
  • 개인 키

일반적으로 개인 키는 VEN 또는 VTN이 보낸 페이로드를 암호화하는 데 사용됩니다. 장치 인증서는 인증 기관에 의해 생성되고 개인 키를 사용하여 암호화된 VEN 또는 VTN에 대한 고유한 식별 정보 세트입니다. 루트 및 중간 file장치 인증서를 해독하고 인증서가 신뢰할 수 있는 기관에서 제공되었는지 확인하는 데 사용됩니다.

JSSE를 사용하는 Java 환경에는 두 개의 인증서 저장소가 있습니다. 하나는 신뢰 저장소라고하며 루트 인증서를 보유하는 데 사용됩니다. 두 번째는 키 저장소라고하며 장치 인증서 중간 인증서와 개인 키로 구성된 인증서 체인을 저장하는 데 사용됩니다.

XMPP 전송을 사용할 때 VEN은 VTN과 직접 통신하는 것이 아니라 XMPP 서버와 통신합니다. 따라서 XMPP 서버의 인증서 구성은 VTN의 구성과 동일해야합니다. VTN 자체와 XMPP 서버 간의 통신은 VEN에 투명하며 본질적으로 개인 링크입니다. 그럼에도 불구하고 대부분의 공급 업체는 XMPP 서버와 통신 할 때 VTN에서 VEN 인증서 세트를 사용했습니다.

OpenFire를 XMPP 서버로 사용하는 경우 고려해야 할 또 다른 제약이 있습니다. OpenFire는 클라이언트 장치 인증서에 사용 된 CN 이름이 XMPP 서버에 구성된 장치 XMPP 사용자 이름과 일치해야합니다. 이로 인해 MAC과 유사한 주소가 VEN 인증서의 CN 이름에 사용되므로 일부 이상한 클라이언트 이름이 발생할 수 있습니다 (OpenADR 보안 요구 사항의 일부).

마지막으로 전송 클라이언트 역할을 할 때 대부분의 VEN 및 VTN은 전송 서버에서 제공하는 인증서의 CN 필드에 인증서를 제공 한 엔티티의 호스트 이름과 일치하는 CN 이름이 있는지 확인하려고 시도합니다. 이것은 인증서를 교환 할 때 상호 운용성 문제의 또 다른 원인이 될 수 있습니다. 호스트 이름 확인은 일반적으로 이러한 종류의 문제를 격리하기 위해 프로그래밍 방식으로 비활성화 할 수 있습니다.

OpenADR 2.0 수요 응답 프로그램 가이드 – 다운로드 [최적화 됨]
OpenADR 2.0 수요 응답 프로그램 가이드 – 다운로드

참고문헌

댓글을 남겨주세요

이메일 주소는 공개되지 않습니다. 필수 항목은 표시되어 있습니다. *