IEC PAS 62746-10-1:2014

IEC PAS 62746-10-1 ®
Edition 1.0 2014-02
PUBLICLY AVAILABLE
SPECIFICATION
PRE-STANDARD
colour
inside
Systems interface between customer energy management system and the power
management system –
Part 10-1: Open Automated Demand Response (OpenADR 2.0b Profile
Specification)
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form

or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or

your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00

CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 14
documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 55 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,

77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
IEC PAS 62746-10-1 ®
Edition 1.0 2014-02
PUBLICLY AVAILABLE
SPECIFICATION
PRE-STANDARD
colour
inside
Systems interface between customer energy management system and the

power management system –
Part 10-1: Open Automated Demand Response (OpenADR 2.0b Profile

Specification)
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
XD
ICS 33.200 ISBN 978-2-8322-1435-0

– 2 – PAS 62746-10-1 © IEC:2014(E)

CONTENTS
FOREWORD . 4

Original introductory material . 6

1 Scope . 9

2 Normative References . 11

3 Non-Normative References. 13

4 Terms and Definitions . 14
5 Abbreviations . 15
6 Overview . 16
6.1 Node and Device Types . 17
6.2 Energy Interoperation Services . 18
6.3 Feature Sets . 18
6.4 Assumptions . 19
7 OpenADR 2.0 Feature Set Profiles . 20
7.1 Differences between OpenADR 2.0a and OpenADR 2.0b . 20
7.2 OpenADR 2.0b Feature Set Profile . 21
7.2.1 Supported Services . 21
7.2.2 Report Only VENs . 21
7.2.3 Transport Mechanism . 22
7.2.4 Security . 22
8 OpenADR 2.0b Services and Data Models Extensions . 23
8.1 OpenADR 2.0b EiEvent Service . 23
8.1.1 Data Model . 26
8.1.2 UML Models . 27
8.2 Differences between OpenADR2.0a and 2.0b Event Mechanism . 29
8.2.1 Event Targets and Resources . 29
8.2.2 OpenADR 2.0b Signal Definitions . 29
8.3 OpenADR 2.0b Report Service . 33
8.3.1 Introduction . 33
8.3.2 Core Reporting Operations . 34
8.4 OpenADR 2.0b Registration Service . 40

8.4.1 Service Operations . 40
8.4.2 Registration Information . 43
8.5 OpenADR 2.0b EiOpt Service . 44
8.5.1 Service Operations . 44
8.5.2 Detail Requirements . 46
8.6 OpenADR Poll . 47
8.7 Application Error Codes. 50
9 Transport Protocol . 51
9.1 Simple HTTP . 51
9.1.1 PUSH and PULL implementation . 51
9.1.2 Service Endpoint URIs . 51
9.1.3 HTTP Methods . 52
9.1.4 Failure Conditions . 52
9.1.5 HTTP Response Codes . 52

PAS 62746-10-1 © IEC:2014(E) – 3 –

9.1.6 Message Timeouts . 53

9.1.7 Message Retry / Quiesce Behavior . 53

9.1.8 PULL Timing . 53

9.1.9 HTTP Headers . 53

9.2 Transport Specific Security . 54

9.3 XMPP . 54

9.3.1 PUSH and PULL implementation . 54

9.3.2 Service Endpoints. 54

9.3.3 Service Execution . 55

9.3.4 Implementation of XMPP Features for OpenADR . 55

9.3.5 Security Considerations . 58
10 OpenADR 2.0 Security . 59
10.1 Architecture and Certificate Types . 59
10.2 Certificate Authorities . 60
10.3 Certificate Revocation . 60
10.4 TLS and Cipher Suites . 60
10.5 System Registration Process . 61
10.5.1 Certificate Fingerprints . 61
10.6 Implementing XML Signatures for OpenADR 2.0 Message Payloads . 61
10.6.1 Introduction to XML Signature . 61
10.6.2 Components of XML Signatures . 62
10.6.3 Creating XML Signatures . 62
10.6.4 Verifying XML Signatures . 63
11 Conformance . 64
11.1 OpenADR 2.0 conformance statement . 64
11.2 OpenADR 2.0b Profile Conformance Rules. 64
11.2.1 EiEvent – from 2.0a . 64
11.2.2 EiEvent – Additional 2.0b Conformance Rules . 73
11.2.3 EiOpt . 75
11.2.4 EiReport . 78
11.2.5 EiRegisterParty . 87
11.2.6 General Conformance Rules . 89
11.3 Cardinality . 95
11.4 Services used from OASIS Energy Interoperation V1.0 Standard . 95
11.5 Services not currently used from OASIS EI . 96

Annex A – Detailed Report Description . 97
Annex B – B Profile Extensions . 98
B.1 Overview . 98
B.2 Report Extension . 98
B.3 Signal Extensions . 98
B.4 Other Extensions . 98
Annex C – oadrPoll Scenarios . 100
C.1 Overview . 100
C.2 Scenarios . 100

– 4 – PAS 62746-10-1 © IEC:2014(E)

INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
SYSTEMS INTERFACE BETWEEN CUSTOMER ENERGY

MANAGEMENT SYSTEM AND THE POWER MANAGEMENT SYSTEM –

Part 10-1: Open Automated Demand Response

(OpenADR 2.0b Profile Specification)

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.

A PAS is a technical specification not fulfilling the requirements for a standard, but made
available to the public.
IEC-PAS 62746-10-1, submitted by Open ADR Alliance, has been processed by IEC project
committee 118: Smart grid user interface. It is based on Open Automated Demand Response
Communications Specification, also called OpenADR 2.0 Specification B Profile. The structure
and editorial rules used in this PAS reflect the practice of the organization which submitted it.
The text of this PAS is based on the This PAS was approved for
following document: publication by the P-members of the
committee concerned as indicated in
the following document
Draft PAS Report on voting
118/29/DPAS 118/32/RVD
PAS 62746-10-1 © IEC:2014(E) – 5 –

Following publication of this PAS, the technical committee or subcommittee concerned may

transform it into an International Standard.

This PAS shall remain valid for an initial maximum period of 3 years starting from the

publication date. The validity may be extended for a single period up to a maximum of 3 years,

at the end of which it shall be published as another type of normative document, or shall be

withdrawn.
One of the tasks of PC 118 is to develop IEC standards on Demand Response.

This document has been approved as an IEC Publicly Available Specification (PAS) following
the decision made by PC 118 at its second plenary meeting (March 2013).
It has been submitted by the OpenADR Alliance which has a category D liaison with PC 118
working groups.
The intent of this publication is to present a widely used technical solution for Demand
Response and a promising trend of the industry. It has a large but partial compatibility with
IEC CIM (IEC 61970 and IEC 61968). Considering the urgent need of industry that is starting
to move ahead and cannot wait, the PAS can temporarily be used as a reference, and gives
time for IEC to develop a formal technical specification (TS) or an international standard (IS)
on Demand Response based on OpenADR 2.0b, fully compatible with IEC CIM which will then
replace this IEC PAS.
The content of this document is based on the Open Automated Demand Response
Communications Specification also called OpenADR 2.0 Specification B Profile. OpenADR is
designed to facilitate automated DR actions at the customer location and has been field
tested and deployed for several years in a number of DR programs in the world.
This standard contains attached Profile B Schema files. These files are intended to be used
as a complement and do not form an integral part of the PAS.
A bilingual version of this publication may be issued at a later date.

– 6 – PAS 62746-10-1 © IEC:2014(E)

Original introductory material

FOREWORD
The development of the Open Automated Demand Response Communications

Specification, also called OpenADR, began in 2002 following the California electricity crisis.

The California Energy Commission Public Interest Energy Research Program funded an
OpenADR research program through the Demand Response Research Center (DRRC) at
Lawrence Berkeley National Laboratory (LBNL). OpenADR development began in 2002 to
support California’s energy policy objectives to move toward dynamic pricing to improve the
economics and reliability of the electric grid. Initial field tests focused on automating a number
of event-based DR utility programs for commercial and industrial (C&I) customers. The DRCC
research set out to determine if today’s communications and information technologies could
be used to automate Demand Response (DR) operations using standardized electricity price
and reliability signals. This research, development, and deployment have led to commercial
adoption of OpenADR. Today, utilities and governments worldwide are using OpenADR to
manage the growing demand for electricity and peak capacity of the electric systems. This low
cost communications infrastructure is used to improve the reliability, repeatability, robustness,
and cost-effectiveness of DR.
OpenADR is a fundamental element of U.S. Smart Grid interoperability standards being
developed to improve optimization between electric supply and demand. OpenADR is
designed to facilitate automated DR actions at the customer location, whether it involves
electric load shedding or shifting. OpenADR is also designed to provide continuous dynamic
price signals such as hourly day-ahead or day-of real time pricing. OpenADR has been field
tested and deployed in a number of DR programs in U.S and worldwide. While the scope of
OpenADR focuses on signals for DR events and prices, significant work focuses on DR
strategies and techniques to automate DR within facilities. OpenADR interacts with facility
control systems that are pre-programmed to take action based on a DR signal, enabling a
response to a DR event or a price to be fully automated, with no manual intervention.
The DRCC OpenADR 1.0 specification was donated to the Organization of Structured
Information Standards (OASIS) to create a national standard for OpenADR. The OASIS’
Energy Interoperation (EI) Technical Committee (TC) developed a standard to describe “an
information model and a communication model to enable collaborative and transactive use of
energy, service definitions consistent with the OASIS SOA Reference Model [SOA-RM], and
XML vocabularies for the interoperable and standard exchange of dynamic price signals,
reliability signals, emergency signals, communication of market participation information such
as bids, load predictability and generation information.” Considering that the goal of OASIS EI

TC was more than DR and Distributed Energy Resources (DER), the EI TC created profiles
within the EI Version 1.0 standard for specific applications within the Smart Grid. The
OpenADR Alliance used the EI OpenADR profile as the basis for the OpenADR 2.0 Profile
Specification defined in this document. OpenADR 2.0 defines profiles for DR and Distributed
Energy Resources (DER), while keeping in mind the requirements of the diverse market and
stakeholder needs.
PAS 62746-10-1 © IEC:2014(E) – 7 –

INTRODUCTION
Development of the Demand Response (DR) market has resulted in a transition from manual

DR to OpenADR in Automated DR (Auto-DR) programs. As of 2013, over 250 MW was

enrolled in California commercial and industrial customers Auto-DR programs using OpenADR

1.0. DR is defined as “…action taken to reduce electricity demand in response to price,

monetary incentives, or utility directives so as to maintain reliable electric service or avoid
high electricity prices.” OpenADR 1.0 was developed to support Auto-DR programs and

California’s energy policy objectives to move toward dynamic pricing to improve the

economics and reliability of the electric grid. The recent developments have expanded the use
of OpenADR to meet diverse market needs such as ancillary services (Fast DR), dynamic
prices, intermittent renewable resources, supplement grid-scale storage, electric vehicles, and
load as generation. For example, with real-time price information, an automated client within
the customer facility can be designed to continuously monitor these prices and translate this
information into continuous automated control and response strategies. This rationale is a
fundamental element of the United States (U.S.) Smart Grid interoperability standards, which
are developed to improve dynamic optimization of electric supply and demand.

OpenADR Communications have the following defining features:

● Continuous, Secure, and Reliable - Provides continuous, secure, and reliable two-
way communications infrastructures where the end points at the end-use site receive
and acknowledge the receipt of DR signals from the energy service providers.
● Translation - Translates DR event information to continuous Internet signals to
facilitate DR automation. These signals are designed to interoperate with energy
management and control systems, lighting, or other end-use controls.
● Automation - Receipt of the external signal is designed to initiate automation through
the use of pre-programmed demand response strategies determined and controlled by
the end-use participant.
● Opt-Out - Provides opt-out or override function to any participants for a DR event if
the event comes at a time when changes in end-use services are not desirable.
● Complete Data Model - Describes a rich data model and architecture to communicate
price, reliability, and other DR activation signals.
● Scalable Architecture - Provides scalable communications architecture to different
forms of DR programs, end-use buildings, and dynamic pricing.
● Open Standards - Open standards-based technology such as Internet Protocol (IP)
and web services form the basis of the communications model.

OpenADR is a communications data model, along with transport and security mechanisms,

which facilitate information exchange between two end-points, the electricity service provider
and the customer. It is not a protocol that specifies “bit-structures” as some communications
protocols do, but instead relies upon existing open standards such as eXtensible Mark-up
Language (XML) and Internet Protocol (IP) as the framework for exchanging DR signals. In
some references the term “system,” “technology,” or “service” is used to refer to the features
of OpenADR.
OpenADR is designed to facilitate automation of DR actions at the customer location, whether
it involves electric load shedding or load shifting. We are often asked if the communications
data model can be used for continuous operations. The answer is yes. Many emergency or

Piette, Mary Ann, Girish Ghatikar, Sila Kiliccote, Ed Koch, Dan Hennage, Peter Palensky, and Charles McParland.
2009. Open Automated Demand Response Communications Specification (Version 1.0). California Energy
Commission, PIER Program. CEC‐ 500‐ 2009‐ 063.
U.S. Federal Energy Regulatory Commission (FERC), 2007 Assessment of Demand Response and Advanced
Metering, Staff Report, available: http://www.ferc.gov/legal/staff-reports/09-07-demand-response.pdf

– 8 – PAS 62746-10-1 © IEC:2014(E)

reliability DR events occur at specific times when the electric grid is strained. The OpenADR

communications are designed to coordinate such signals with facility control systems

(commercial, industrial, and residential). OpenADR is also designed to provide continuous

dynamic price signals such as hourly day-ahead or day-of real time pricing. With such price

information an automated client can be configured to continuously monitor these prices and

translate this information into continuous automated control and response strategies within a
facility. Several reports present the history of OpenADR 1.0 research. This OpenADR 2.0
profile specification covers the signaling data models for price and reliability signals to both
wholesale and retail markets in the U.S.

OpenADR provides the following benefits:

● Open Specification–Provides a standardized DR communications and signaling
infrastructure using open, non-proprietary, industry-approved data models that can be
implemented for both dynamic prices and DR emergency or reliability events.
● Flexibility–Provides open communications interfaces and protocols that are flexible,
platform-independent, interoperable, and transparent to end-to-end technologies and
software systems.
● Innovation and Interoperability–Encourages open innovation and interoperability,
and allows controls and communications within a facility or enterprise to build on
existing strategies to reduce technology operation and maintenance costs, stranded
assets, and obsolesce in technology.
● Ease of Integration–Facilitates integration of common Energy Management and
Control Systems (EMCS), centralized lighting, and other end-use devices that can
receive Internet signals (such as XML).
● Supports Wide Range of Information Complexity – Can express the information in
the DR signals in a variety of ways to allows for systems ranging from simple end
devices (e.g., thermostats) to sophisticated intermediaries (e.g., aggregators) to
receive the DR information that is best suited for its operations.
● Remote Access– Facilitates opt-out or override functions for participants to manage
standardized DR-related operation modes to DR strategies and control systems.

The OpenADR Alliance is the primary authority for the development and adoption of
OpenADR, leveraging the OpenADR 1.0 activities and OASIS Energy Interoperation (EI)
Technical Committee’s Version 1.0 standard. The OpenADR profile within OASIS EI Version
1.0 standard is the basis for the OpenADR 2.0 profile specification and is referenced as
appropriate in this document.
These reports are available at http://drrc.lbl.gov/drrc-pubsall.html:
Piette, M.A., S. Kiliccote, G. Ghatikar, Design and Implementation of an Open, Interoperable Automated Demand
Response Infrastructure, Proceedings of the Grid-Interop Forum, October 2007, LBNL-63665.
Koch, E., M.A. Piette, Architecture Concepts and Technical Issues for an Open, Interoperable Automated Demand
Response Infrastructure. Proceedings of the Grid-Interop Forum, October 2007. LBNL-63664.
Piette, M.A, D. Watson, N. Motegi, S. Kiliccote Automated Critical Peak Pricing Field Tests: 2006 Pilot Program
Description and Results, August, 2007. LBNL-62218.
Motegi, N., M.A. Piette, D.S. Watson, S. Kiliccote, P. Xu. Introduction to Commercial Building Control Strategies
and Techniques for Demand Response, May 2007. LBNL-59975.
Energy Interoperation OASIS Committee Specification, Energy Interoperation Version 1.0, December 2011.
http://www.oasis-open.org/committees/download.php/44364/energyinterop-v1.0-csprd03.zip

PAS 62746-10-1 © IEC:2014(E) – 9 –

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

– 10 – PAS 62746-10-1 © IEC:2014(E)

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

PAS 62746-10-1 © IEC:2014(E) – 11 –

2 Normative References
- [OpenADR 2.0 PICS] – Source: OpenADR website, http://www.openadr.org

- [OpenADR 2.0 Certificate Policy] – Source: OpenADR website,

http://www.openadr.org
- [OASIS EI 1.0] Energy Interoperation OASIS Committee Specification 02, Energy

Interoperation Version 1.0, http://docs.oasis-

open.org/energyinterop/ei/v1.0/cs02/energyinterop-v1.0-cs02.html, February 2012.

- [OASIS EMIX 1.0] EMIX OASIS Committee Specification 02, Energy Market
Information Exchange 1.0, http://docs.oasis-open.org/emix/emix/v1.0/cs02/emix-v1.0-
cs02.html, January 2012.
- [OASIS WS-Calendar] WS-Calendar OASIS Committee Specification 1.0, WS-
Calendar, http://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/cs01/ws-
calendar-spec-v1.0-cs01.html, July 2011.
- [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,
http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

- [RFC2246] T. Dierks, C. Allen, The TLS Protocol Version 1.0,
http://www.ietf.org/rfc/rfc2246.txt, IETF RFC 2246, January 1999.

- [RFC2616] R. Fielding et. al., Hypertext Transfer Protocol -- HTTP/1.1,
http://www.ietf.org/rfc/rfc2616.txt, IETF RFC 2616, June 1999.

- [RFC3275] D. Eastlake, J. Reagle, D. Solo, (Extensible Markup Language) XML-
Signature Syntax and Processing, http://www.ietf.org/rfc/rfc3275.txt, IETF RFC 3275,
March 2002.
- [RFC3986] T. Berners-Lee et. al., Uniform Resource Identifier (URI): Generic Syntax,
http://www.ietf.org/rfc/rfc3986.txt, IETF RFC 3986, June 1999.

- [RFC4346] T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol
Version 1.1, http://www.ietf.org/rfc/rfc4346.txt, IETF RFC 4346, April 2006.

- [RFC5246] T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol

Version 1.2, http://www.ietf.org/rfc/rfc5246.txt, IETF RFC 5246, April 2008.

- [RFC6120] P. Saint-Andre, Extensible Messaging and Presence Protocol (XMPP):
Core Version 1.0, http://www.ietf.org/rfc/rfc6120.txt, IETF RFC 6120, March 2011.

- [RFC6121] P. Saint-Andre, Extensible Messaging and Presence Protocol (XMPP):
Instant Messaging and Presence, http://www.ietf.org/rfc/rfc6121.txt, IETF RFC 6121,
March 2011.
- [RFC6122] P. Saint-Andre, Extensible Messaging and Presence Protocol (XMPP):
Address Format, http://www.ietf.org/rfc/rfc6122.txt, IETF RFC 6122, March 2011.

- [SOA-RM] SOA-RM OASIS Standard, OASIS Reference Model for Service Oriented
Architecture 1.0, http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.html, October 2006.

– 12 – PAS 62746-10-1 © IEC:2014(E)

- [XEP-0030] Joe Hildebrand et. al., XEP-0030: Service Discovery,

http://xmpp.org/extensions/xep-0030.html, June 2006.

PAS 62746-10-1 © IEC:2014(E) – 13 –

3 Non-Normative References
- OpenADR 2.0a Profile Specification

- UCA OpenSG OpenADR security profile

- IRC and NAESB requirements/use-cases

- NIST Special Publication 800-131A

- NAESB REQ.21 Energy Services Provider Interface (ESPI), Version 1.0 October
2011(Green Button)
– 14 – PAS 62746-10-1 © IEC:2014(E)

4 Terms and Definitions
The OpenADR Alliance: The OpenADR Alliance is comprised of industry stakeholders that

are interested in fostering the deployment of low-cost price- and reliability-based demand

response communication protocol by facilitating and accelerating the development and

adoption of OpenADR standards and compliance with those standards. These include de

facto standards based on specifications published by LBNL in April 2009, as well as Smart

Grid-related standards emerging from OASIS, UCAIug, NAESB, and IRC.

OpenADR 2.0 Profile Specification: The OpenADR 2.0a and 2.0b Profile Specifications

provide specific implementation related information in order to build an OpenADR enabled

device or system. Developers shall use the Profile Specification in conjunction with the
schemas, sample payloads, PICS and test plans.
OASIS Energy Interoperation (EI): Energy Interoperation standard describes information and
communication model to coordinate energy supply, transmission, distribution, and use,
including power and ancillary services, between any two parties, such as energy suppliers
and customers, markets and service providers, in any of the domains defined in the Smart
Grid. The EI 1.0 standard was used as a basis for OpenADR 2.0 Profile Specification.
Demand Response: A mechanism to manage customer load demand in response to supply
conditions, such as prices or availability signals.
Slow DR: Demand Response where the signals are sent significantly before the events are
called, such as day-ahead.
Fast DR: Fast Demand Response or Fast DR refers to programs that require a (much) faster
than usual response time. While typical peak shaving DR programs have minutes, if not hours
or days, of lead-time, these programs have lead times of seconds (e.g., 4 second response
time) used for load balancing and frequency stabilization (e.g., ancillary services and
regulation services)
PUSH/PULL operations: OpenADR 2.0 can be used in either PULL mode (VEN pulling
information from VTN) or in a PUSH mode in the simple HTTP transport. The XMPP transport
uses a PUSH model, although VENs can still make requests of the VEN, excluding the use of
oadrPoll.
Simple HTTP: Simple HTTP in OpenADR 2.0 (a/b) refers to an HTTP implementation that
uses HTTP POST over TLS to propagate OpenADR payloads.

The upper-case key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,

“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in [RFC2119].

PAS 62746-10-1 © IEC:2014(E) – 15 –

5 Abbreviations
AutoDR: Automated Demand Response

DER: Distributed Energy Resources

DR: Demand Response
DRRC: Demand Response Research Center

DUT: Device Under Test
EI: Energy Interoperation
HTTP: Hyper Text Transfer Protocol
IRC: ISO/RTO Council
ISO: Independent Systems Operator
JID: Jabber Identifiers
LBNL: Lawrence Berkeley National Laboratory
NAESB: North American Energy Standards Board
OASIS: Organization of Structured Information Standards
OpenADR: Open Automated Demand Response
PICS: Protocol Implementation Conformance Statement
RTO: Regional Transmission Operators
SASL: Simple Authentication and Security Layer
Simple HTTP: Limited REST transport protocol

SOAP: Simple Object Access Protocol
TC: Technical Committee
UCAIug: Utilities Communications Archite
...