OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

Messages By Date: members message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Proposed Charter for OASIS Energy Interoperation TC

To OASIS Members:

  A draft TC charter has been submitted to establish the OASIS Energy Interoperation Technical Committee (below). In accordance with the OASIS TC Process Policy section 2.2:
(http://www.oasis-open.org/committees/process-2008-06-19.php#formation) the proposed charter is hereby submitted for comment. The comment period shall remain open until 11:45 pm ET on 27 April 2009.

  OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending email to:
mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will be publicly archived at:
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page:
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail.

  A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend within four days of the close of the comment period. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar.

  We encourage member comment and ask that you note the name of the proposed TC (energy-interop) in the subject line of your email message.



Mary P McRae
Director, Technical Committee Administration
OASIS: Advancing open standards for the information society
phone: 1.603.232.9090

OASIS Energy Interoperation Technical Committee Draft Charter

a. The name of the TC:
OASIS Energy Interoperation TC  

b. Statement of Purpose:

Energy markets have been characterized by poor coordination of supply and demand. This failing has exacerbated the problems caused by rising energy demand. In particular, poor communications concerning times of peak use cause economic loss to energy suppliers and consumers. There are today a limited number of high demand periods (roughly ten days a year, and only a portion of those days) when the failure to manage peak demand causes immense costs to the provider of energy; and, if the demand cannot be met, expensive degradations of service to the consumer of energy. As the proportion of alternative energies on the grid rises, and more energy comes from unreliable sources, the frequency and scale of these problems will increase.

Energy consumers can use a variety of technologies and strategies to shift energy use to times of lower demand and also to reduce use during peak periods. This shifting and reduction can reduce the need for new power plants, and transmission and distribution systems. These changes will reduce the overall costs of energy through greater economic efficiency. This process is called various names, including Demand Response (DR), demand shaping, and load shaping. 

Distributed energy generation now challenges the traditional hierarchical relationship of supplier and consumer. Alternative and renewable energy sources may be placed closer to the end nodes of the grid. Wind and solar generation, as well as industrial co-generation, allow end nodes to sometimes be energy suppliers. Energy storage, particularly in plug-in hybrid vehicles, means that the same device may be sometimes a supplier, sometime a consumer. As these sources are all intermittent, they increase the challenge of coordinating supply and demand to maintain the reliability of the electric grid. 

Better communication of energy prices addresses growing needs for lower-carbon, lower-energy buildings, net zero-energy systems, and supply-demand integration that take advantage of dynamic pricing. Local generation and local storage require that the consumer (in today's situation) make investments in technology and infrastructure including electric charging and thermal storage systems. Buildings and businesses and the power grid will benefit from automated and timely communication of energy pricing, capacity information, and other grid information.

Consistency of technology for interoperation and standardization of data communication can allow essentially the same model to work for homes, small businesses, commercial buildings, office parks, neighborhood grids, and industrial facilities, simplifying interoperation across the broad range of energy providers, distributors, and consumers, and reducing costs for implementation.

These communications will involve energy consumers, producers, transmission systems, and distribution systems. They must enable aggregation for production, consumption and curtailment resources. Market makers, such as Independent System Operators (ISOs), utilities, and other evolving mechanisms need to be supported so that interoperation can be maintained as the Smart Grid evolves. Beyond these interfaces, building and facility agents can make decisions on energy sale purchase and use that fit the goals and requirements of their home, business, or industrial facility. 

The new symmetry of energy transactions demands symmetry of interface. A net consumer of energy may be a producer when the sun is shining, the wind is blowing, or a facility is producing co-generated energy. Each interface must support symmetry as well, with energy and economic transactions flowing each way.

In addition to architectural symmetry, this Technical Committee should create composed and composable specifications that leverage existing technologies (such as OASIS fine-grained web services security standards and reliable messaging standards) rather than reinventing. These specifications will define service interfaces and the data on which they operate to allow interoperation without requiring deep knowledge of the systems as they are implemented.

The Technical Committee will define the interaction of Smart Grids with their end nodes: Smart Buildings and Facilities, Enterprises, Industry, Homes, and Vehicles. Dynamic pricing, reliability, and emergency signals must be communicated through interoperability mechanisms that meet business needs, scale, use a variety of communication technologies, maintain security and privacy, and are reliable. We must try to define interoperability in a manner that will work with anticipated changes as well as those we cannot predict as technology changes.

c. Scope:

This TC will leverage existing work wherever feasible, and will produce specifications for interoperation consistent with architectural principles including symmetry, composability, service orientation, and aggregation.

The TC will develop a data model and communication model to enable collaborative and transactive use of energy. Web services definitions, service definitions consistent with the OASIS SOA Reference Model, and XML vocabularies will be developed for 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

In addition to the protocol for exchanging information, optionally the TC may address:
* Information and interfaces between the interoperation endpoints and the implementations at either end

This work will be done to facilitate enterprise interaction with energy markets, including but not limited to:
* Response to emergency and reliability events
* Take advantage of lower energy costs by deferring or accelerating usage
* Enable trading of curtailment and generation
* Support symmetry of interaction between providers and consumers of energy
* Provide for aggregation of provision, curtailment, and use

The definition of a price and of reliability information depends on the market context in which it exists. It is not in scope for this TC to define specifications for markets or for price and bid communication, but the TC will coordinate with others to ensure that commonly used market and pricing models are supported.

Specific work with which the TC intends to coordinate is listed in Section (2)(a).

d. List of Deliverables:

Projected times are from inception, the date of the initial TC meeting.

Insofar as possible the TC will coordinate its schedules with UCAI and other initiatives including those supported by NIST and related regulatory agencies.

The terminology in this section is drawn from the OpenADR specification Version 1.0. The simplified role names we use in this section are "consumer," the consumer of energy (also called the participant) and the "provider," the provider of energy (also called "utility" or "Independent System Operator [ISO]" or "aggregator"). These names are not definitive.

(1) Model and terminology: The terminology and model used to describe the interoperation protocol endpoints and message contents (3 months)

(2)  Consumer-Provider [Participant-Operator] Interoperation Specification: The messages and protocol addressing the functions and data model in the OpenADR Participant Operator Interface (6 months)

(3)  Demand Response Automation Server Interface Specification: The functions and data model entities for DRAS Client Interface to allow effective use of the Energy Interoperation protocols to retrieve and provide information to facilities' systems (9 months)

(4)  Utility, ISO Operator, and Aggregator Interface Specification: Additional semantic models useful for functions within Participant Operator and/or DRAS Client Interfaces (see scope). (12 months).

(5)  Energy Interoperation Specification Version 1. (14 months).

After the first deliverable is complete, the TC will enter "maintenance mode."  The maintenance is intended to provide minor revisions to address inconsistencies and any necessary modifications in a way that does not affect core structure and functionality of the final deliverable. Such updates will take place at least annually.

The TC will also continue to address the interoperation; the bindings for communication within OpenADR specification from the connection point within the supply and demand-side or the utility or ISO and the facility.

e. IPR Mode
The TC shall operate under RF on Limited Terms.

f. Anticipated Audience
Anticipated users of this work include:
* Implementers of facility agents, embedded communications clients in control systems, and gateways
* Market makers and participants such as Independent System Operators
* Aggregators of energy provision, curtailment, and use
* Consumers of energy for acquiring energy in a cost-effective manner consistent with their business and/or personal activities
* Transmission, distribution, and utilities

g. Language
The TC will use English as the language for conducting its operations.

(2) Non-normative information regarding the startup of the TC: 
(2)(a) Identification of similar or applicable work that is being done in other OASIS TCs or by other organizations, why there is a need for another effort in this area and how this proposed TC will be different, and what level of liaison will be pursued with these other organizations.

There is no standard for interaction and interoperation in this space.

The Demand Response Research Center (http://drrc.lbl.gov) at Lawrence Berkeley National Laboratory (http://www.lbl.gov) has defined a specification called "Open Automated Demand Response Communication Specification (Version 1.0)," also known as OpenADR or Open Auto-DR, (http://openadr.lbl.gov), which addresses many of the issues described in the Charter. Since May 2008, OpenADR has gone through two major public drafts and is being used commercially and as pilots by several utilities in the states of California and Washington in the U.S. OpenADR is one element of the evolving Smart Grid information and communications technologies that are being developed to improve collaboration between electric supply and demand. 

The LBNL OpenADR body of work is being extended through two organizations being created: this proposed OASIS TC and the proposed UCAIug OpenADR Task Force.  

OpenADR will be contributed to the TC at its inception (see Section (2)(g).

The UCA International Users Group (http://www.ucaiug.org/) is a not-for-profit corporation bringing together utilities and supplier companies. An innovative collaboration is being developed that will focus goals and requirements from utility and utility supplier stakeholders as input to the definition of XML vocabularies and interoperation specifications by this TC. 

We anticipate that the UCAIug OpenADR Task Force (in formation) will accept responsibility for refining and evolving the technology independent requirements and information model contributed by the LBNL OpenADR effort, and for focusing and providing requirements input from the utility and energy service provider perspective to the OASIS TC and other bodies developing technology specific implementations.  We anticipate that that task force will also accept responsibility for developing consensus regarding DR requirements and information exchange from other UCAIug Working Groups, Task Forces, and alliances including AMI-Enterprise, CIMug, and the ZigBee/HomePlug alliance, and for collaboration with the OASIS TC through timely contributed models, requirements, and comments on technical work. 

This OASIS TC is responsible for defining and evolving the XML technology specific aspects of this work, including but not limited to data models, XML vocabularies, Web services definitions, and protocols for information exchange, engage in analyzing and clarifying goals and requirements, and managing public and other reviews and inputs to the OASIS standardization process.

The UCAIug provides focused input from a significant group of stakeholders, but not the entire range of potential users of the planned work of the TC. Accordingly, we are working to engage with other groups of stakeholders to allow similar requirements and information model collaboration.

We believe that close coordination and balancing among the full range of stakeholders is essential to ensure that a single, technology independent requirements specification and abstract information model can be developed that can be implemented by the OASIS TC and any other entities that may develop non-XML profiles, thus assuring interoperation at the model level in the future. 

The utilities, Independent System Operators (ISOs), energy market makers, and wholesale energy market participants have defined interactions that could support and contribute to this TC's work. We welcome them as stakeholders and potential contributors.

We anticipate input from technology, policy and business stakeholders and organizations, including but not limited to NIST Domain Expert Working Groups (NIST DEWG) and Task Groups  (http://www.nist.gov/smartgrid/), The Federal Energy Regulatory Commission (FERChttp://www.ferc.gov), the National Association of Regulatory Utility Commissioners (NARUC http://naruc.org/) and the Electric Power Research Institute (EPRI  http://www.epri.com).

The development of open, transactive energy is a goal of the GridWise Architecture Council (http://www.gridwiseac.org/). We expect to engage the members throughout the lifecycle of the TC, as well as with emerging Smart Grid Architecture efforts from NIST.

The definition of a market is a required context for understanding prices, pricing, and bids. Market definition is outside the scope of this TC; we expect to interact with work developing out of the 2009 GridEcon conference (http://www.gridecon.com/2009/), NIST, and the evolving Smart Grid Architecture. We anticipate that an Energy Market Information Exchange Technical Committee will be formed to define details of prices and bids in a manner usable by and consistent with OpenADR per a draft charter at http://lists.oasis-open.org/archives/smartgrid-interest/200903/msg00003.html .

Work on defining business attributes of a service, being developed by the OASIS Service Oriented Architecture End-to-End Resource Planning TC (SOA-EERP TC), may apply to define attributes of energy.

The (proposed, in formation) OASIS WS-Calendaring Technical Committee will be creating an interoperable XML vocabulary and model for time that is applicable to energy pricing and automated building management. We expect to coordinate with that TC when it is formed.

Composability with the WS-Transaction family of OASIS Standards may be beneficial for consistent distributed outcomes, particularly across enterprises with diverse ownership.

Service definitions and the approach of the TC should be consistent with the OASIS Service Oriented Architecture Reference Model (http://www.oasis-open.org/specs/#soa-rmv1.0) and industry practice in that area.


Version 1.0 CEC and LBNL report: 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-XXX [final number pending].

(2)(b) The date, time, and location of the first meeting, whether it will be held in person or by phone, and who will sponsor this first meeting. The first meeting of a TC shall occur no less than 30 days after the announcement of its formation in the case of a telephone or other electronic meeting, and no less than 45 days after the announcement of its formation in the case of a face-to-face meeting.

The initial meeting will be a teleconference on 22 June 2009 at 1pm EDT / 10am PDT.

(2)(c) The projected on-going meeting schedule for the year following the formation of the TC, or until the projected date of the final deliverable, whichever comes first, and who will be expected to sponsor these meetings.

The TC will conduct its business via weekly teleconference calls. The time of the call will be determined during the first meeting of the TC. The TC will conduct face-to-face meetings as needed and determined by the TC. The TC participants will sponsor teleconference facilities and face-to-face meetings.

Time zone difference of participants may require flexibility in meeting times, quorum, and subcommittees (if any).

(2)(d) The names, electronic mail addresses, and membership affiliations of at least Minimum Membership who support this proposal and are committed to the Charter and projected meeting schedule.

Anto Budiardjo, anto@clasma.com, Individual
Edward Cazalet, ed@cazalet.com, Individual
Toby Considine, Toby.Considine@unc.edu, University of North Carolina
William Cox, wtcox@CoxSoftwareArchitects.com, Individual
Rik Drummond, rikd@drummondgroup.com, Drummond Group
Craig Gemmill, craig.gemmill@tridium.com, Tridium, Inc.
Girish Ghatikar, GGhatikar@lbl.gov, Lawrence Berkeley National Laboratory
David Holmberg, david.holmberg@nist.gov, National Institute of Standards and Technology
Jeffrey Kegley, jkegley@tridium.com, Tridium, Inc.
Ed Koch, ed@akuacom.com, Akuacom
Michel Kohanim, michel@universal-devices.com, Individual
Mary Ann Piette, mapiette@lbl.gov, Lawrence Berkeley National Laboratory
Jeremy Roberts, jeremy@lonmark.org, LonMark International
Mike Truskowski, truskows@cisco.com, Cisco Systems Inc.
Matt Wakefield, mwakefield@epri.com, Electric Power Research Institute
Dave Hardin, david.hardin@ips.invensys.com, Invensys Process Controls

(2)(e) The name of the Convener who must be an Eligible Person.
Mary Ann Piette, Lawrence Berkeley National Laboratories, MAPiette@lbl.gov.

(2)(f) The name of the Member Section with which the TC intends to affiliate
The Energy Interoperation TC intends to affiliate with the OASIS BLUE Member Section (in formation).

(2)(g) Optionally, a list of contributions of existing technical work that the proposers anticipate will be made to this TC.

OpenADR WG and Lawrence Berkeley National Laboratory's Demand Response Research Center have agreed to contribute "Open Automated Demand Response Communication Specification (Version 1.0)," also known as OpenADR or Open Auto-DR, (http://openadr.lbl.gov), to the Technical Committee when it is formed.

(2)(h) Optionally, a draft Frequently Asked Questions (FAQ) document regarding the planned scope of the TC, for posting on the TC's website.
Not supplied. See Section 1(b).

(2)(i) Optionally, a proposed working title and acronym for the specification(s) to be developed by the TC. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]