Shopping Cart

No products in the cart.

BSI PD IEC/PAS 62746-10-1:2014

$215.11

Systems interface between customer energy management system and the power management system – Open Automated Demand Response (OpenADR 2.0b Profile Specification)

Published By Publication Date Number of Pages
BSI 2014 106
Guaranteed Safe Checkout
Category:

If you have any questions, feel free to reach out to our online customer service team by clicking on the bottom right corner. We’re here to assist you 24/7.
Email:[email protected]

The OpenADR 2.0 profile specification is a flexible data model to facilitate common information exchange between electricity service providers, aggregators, and end users. The concept of an open specification is intended to allow anyone to implement the two-way signaling systems, providing the servers, which publish information (Virtual Top Nodes or VTNs) to the automated clients, which subscribe the information (Virtual End Nodes, or VENs).

This OpenADR 2.0 profile specification covers the signaling data models between VTN and VEN (or VTN/VEN pairs) and does include information related to specific DR electric reduction or shifting strategies, which are taken at the facility. In particular, OpenADR 2.0 supports the following services from OASIS EI Version 1.0 standard or subset thereof. Extensions to these services are included to meet the DR stakeholder and market requirements:

  1. Registration (EiRegisterParty): Register is used to identify entities such as VEN’s and parties. This is necessary in advance of an actor interacting with other parties in various roles such as VEN, VTN, tenderer, and so forth.

  2. Enrollment (EiEnroll): Used to enroll a Resource for participation in DR programs. This establishes a relationship between two actors as a basis for further interactions. (Planned for future releases)

  3. Market Contexts (EiMarketContext): Used to discover program rules, standard reports, etc. Market contexts are used to express market information that rarely changes, and thereafter need not be communicated with each message. (Planned for future releases)

  4. Event (EiEvent): The core DR event functions and information models for priceresponsive DR. This service is used to call for performance under a transaction. The service parameters and event information distinguish different types of events. Event types include reliability events, emergency events, and more – and events MAY be defined for other actions under a transaction.

  5. Quote or Dynamic Prices (EiQuote): EiDistributeQuote for distributing complex dynamic prices such as block and tier tariff communication. These are sometimes referred to as price signals; such signals are indications of a possible tender price – they are not themselves actionable. Such services can be used to implement the functionality for energy market interactions or transactional energy. (Planned for future releases)

  6. Reporting or Feedback (EiReport): The ability to set periodic or one-time information on the state of a Resource (response).

  7. Availability (EiAvail): Constraints on the availability of Resources. This information is set by the end node and indicates when an event may or may not be accepted and executed by the VEN with respect to a Market Context. Knowing the Availability and Opt information for its VENs improves the ability of the VTN to estimate response to an event or request. (Planned for future releases)

  8. Opt or Override (EiOpt): Overrides the EiAvail; addresses short-term changes in availability to create and communicate Opt-in and Opt-out schedules from the VEN to the VTN.

These OpenADR 2.0 services in this specification provide information that is pertinent to DR, pricing, and DER communication requirements. These services make no assumption on specific DR electric load control strategies within the resource or market-specific contractual or business agreements between electricity service providers and their customers.

OpenADR uses an application-level data model, which is independent of transport mechanisms. For the purposes of interoperability, OpenADR 2.0 provides basic transport mechanisms and their relevant interaction patterns (e.g., PUSH information vs. PULL information) to address different stakeholder needs.

OpenADR 2.0 specifies the necessary level of security that is essential to meet the U.S. Cyber Security requirements for such purposes as data confidentiality, integrity, authentication and message-level security. Such security requirements are essential for nonrepudiation and to mitigate any resulting Cyber Security risks.

OpenADR 2.0 provides a clear set of mandatory and optional attributes within each of the services to meet the broader interoperability, testing and certification requirements, while creating feature-sets with different product profiles to address today’s market needs as well as future requirements that are closely aligned to meet OpenADR goals and national interoperability requirements for Smart Grid standards.

The different product certification levels for OpenADR include OpenADR 2.0a, OpenADR 2.0b, and OpenADR 2.0b “Energy Reporting only” VENs (depicted in Figure 1). VTN certification for 2.0a will end with publication of this document, and existing implementations of 2.0a VTNs must upgrade to the OpenADR2.0b standard. For this reason, Figure 1 has no column for 2.0a VTN. 2.0b VTNs must support 2.0a VENs (and therefore comply with the OpenADR2.0a standard). VENs can be certified using the 2.0a, the 2.0b, and a 2.0b “Energy reporting only” profile. An OpenADR 2.0c or new market-specific profiles may be specified in the future. This profile specification describes OpenADR 2.0b. For the final 2.0a features, please refer to the respective specification, which is available on the OpenADR Alliance’s website – http://www.openadr.org/.

PDF Catalog

PDF Pages PDF Title
4 CONTENTS
6 FOREWORD
8 Original introductory material
11 1 Scope
13 2 Normative References
15 3 Non-Normative References
16 4 Terms and Definitions
17 5 Abbreviations
18 6 Overview
19 6.1 Node and Device Types
20 6.2 Energy Interoperation Services
6.3 Feature Sets
21 6.4 Assumptions
22 7 OpenADR 2.0 Feature Set Profiles
7.1 Differences between OpenADR 2.0a and OpenADR 2.0b
23 7.2 OpenADR 2.0b Feature Set Profile
7.2.1 Supported Services
7.2.2 Report Only VENs
24 7.2.3 Transport Mechanism
7.2.4 Security
25 8 OpenADR 2.0b Services and Data Models Extensions
8.1 OpenADR 2.0b EiEvent Service
28 8.1.1 Data Model
29 8.1.2 UML Models
31 8.2 Differences between OpenADR2.0a and 2.0b Event Mechanism
8.2.1 Event Targets and Resources
8.2.2 OpenADR 2.0b Signal Definitions
35 8.3 OpenADR 2.0b Report Service
8.3.1 Introduction
36 8.3.2 Core Reporting Operations
42 8.4 OpenADR 2.0b Registration Service
8.4.1 Service Operations
45 8.4.2 Registration Information
46 8.5 OpenADR 2.0b EiOpt Service
8.5.1 Service Operations
48 8.5.2 Detail Requirements
49 8.6 OpenADR Poll
52 8.7 Application Error Codes
53 9 Transport Protocol
9.1 Simple HTTP
9.1.1 PUSH and PULL implementation
9.1.2 Service Endpoint URIs
54 9.1.3 HTTP Methods
9.1.4 Failure Conditions
9.1.5 HTTP Response Codes
55 9.1.6 Message Timeouts
9.1.7 Message Retry / Quiesce Behavior
9.1.8 PULL Timing
9.1.9 HTTP Headers
56 9.2 Transport Specific Security
9.3 XMPP
9.3.1 PUSH and PULL implementation
9.3.2 Service Endpoints
57 9.3.3 Service Execution
9.3.4 Implementation of XMPP Features for OpenADR
60 9.3.5 Security Considerations
61 10 OpenADR 2.0 Security
10.1 Architecture and Certificate Types
62 10.2 Certificate Authorities
10.3 Certificate Revocation
10.4 TLS and Cipher Suites
63 10.5 System Registration Process
10.5.1 Certificate Fingerprints
10.6 Implementing XML Signatures for OpenADR 2.0 Message Payloads
10.6.1 Introduction to XML Signature
64 10.6.2 Components of XML Signatures
10.6.3 Creating XML Signatures
65 10.6.4 Verifying XML Signatures
66 11 Conformance
11.1 OpenADR 2.0 conformance statement
11.2 OpenADR 2.0b Profile Conformance Rules
11.2.1 EiEvent – from 2.0a
75 11.2.2 EiEvent – Additional 2.0b Conformance Rules
77 11.2.3 EiOpt
80 11.2.4 EiReport
89 11.2.5 EiRegisterParty
91 11.2.6 General Conformance Rules
97 11.3 Cardinality
11.4 Services used from OASIS Energy Interoperation V1.0 Standard
98 11.5 Services not currently used from OASIS EI
99 Annex A – Detailed Report Description
100 Annex B – B Profile Extensions
B.1 Overview
B.2 Report Extension
B.3 Signal Extensions
B.4 Other Extensions
102 Annex C – oadrPoll Scenarios
C.1 Overview
C.2 Scenarios
BSI PD IEC/PAS 62746-10-1:2014
$215.11