PD IEC/PAS 62746-10-1:2014

Systems interface between customer energy management system and the power management system. Open Automated Demand Response (OpenADR 2.0b Profile Specification) | Status: Current, Work in hand

1 Scope 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. 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. 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. 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. 4. Event (EiEvent): The core DR event functions and information models for price- responsive 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. 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. 6. Reporting or Feedback (EiReport): The ability to set periodic or one-time information on the state of a Resource (response).
7. 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. 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 non- repudiation 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/. Figure 1 — OpenADR 2.0 Certification Levels