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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tc-announce message

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


Subject: Call for Participation: OASIS Energy Interoperation TC



To:  OASIS members & interested parties:

   A new OASIS technical committee is being formed. The OASIS Energy  
Interoperation Technical Committee has been proposed by the members of  
OASIS listed below. The TC name, statement of purpose, scope, list of  
deliverables, audience, and language specified in the proposal will  
constitute the TC's official charter. Submissions of technology for  
consideration by the TC, and the beginning of technical discussions,  
may occur no sooner than the TC's first meeting.

   The eligibility requirements for becoming a participant in the TC  
at the first meeting are:

   (a) you must be an employee of an OASIS member organization or an  
individual member of OASIS, and
   (b) you must join the Technical Committee, which members may do by  
using the "Join this TC" button on the TC's public page at [a].

   To be considered a voting member at the first meeting, you must:
   (a) join the Technical Committee at least 7 days prior to the first  
meeting (15 June 2009); and
   (b) you must attend the first meeting of the TC, at the time and  
date fixed below (22 June 2009).

Of course, participants also may join the TC at a later time. OASIS  
and the TC welcomes all interested parties.

   Non-OASIS members who wish to participate may contact us about  
joining OASIS [b]. In addition, the public may access the information  
resources maintained for each TC: a mail list archive, document  
repository and public comments facility, which will be linked from the  
TC's public home page at [a].

   Please feel free to forward this announcement to any other  
appropriate lists. OASIS is an open standards organization; we  
encourage your participation.

Regards,

Mary

---------------------------------------------------
Mary P McRae
Director, Technical Committee Administration
OASIS: Advancing open standards for the information society
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
phone: 1.603.232.9090

[a] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=energyinterop
[b] See http://www.oasis-open.org/join/



CALL FOR PARTICIPATION
OASIS Energy Interoperation Technical Committee

OASIS Energy Interoperation TC

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 intermittent sources, the  
frequency and scale of these problems will increase. In addition, new  
electric loads such as electric vehicles will increase the need for  
electricity and with new load characteristics and timing.

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 resources, including generation and storage, now  
challenge 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, for example mobile storage 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 means of interaction between  
Smart Grids and their end nodes, including Smart Buildings and  
Facilities, Enterprises, Industry, Homes, and Vehicles. Dynamic  
pricing, reliability, and emergency signals must be communicated  
through interoperability mechanisms that meet business and energy  
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.


Scope:

This TC will leverage existing work wherever feasible, and will  
produce specifications for interoperation consistent with  
architectural principles including symmetry, composability, service  
orientation, usability 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.


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 the UCA  
International Users Group (http://www.ucaiug.org/) [UCAiug] and other  
initiatives including those supported by NIST and 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. The following may be bundled or  
unbundled as the TC work progresses.

(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, Independent System Operator or other transmission  
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 deliverable (5) 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 as well as the  
bindings for communication within OpenADR specification from the  
connection point within the supply and demand-side, or between the  
utility or ISO and the facility.


IPR Mode

The TC shall operate under RF on Limited Terms.


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
* Providers of energy and curtailment
* Consumers of energy for acquiring energy in a cost-effective manner  
consistent with their business and/or personal activities
* Operators of transmission, distribution, and utilities


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

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

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

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 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 and Task Forces under their  
Open Smart Grid Subcommittee, and alliances such as AMI-Enterprise,  
CIMug, OpenHAN, ZigBee Alliance and HomePlug Powerline 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, aggregators, and wholesale energy market participants have  
defined interactions that could support and contribute to this TC's  
work. For example, NAESB has specified some interactions between ISOs  
and DR Aggregators. 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/) 
, the United States Department of Energy, 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.htm 
l.

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.

Consistency with the evolving work involving Emergency Management (the  
OASIS Emergency Management TC) and spatial locations and  
relationships, e.g. standards from the Open Geospatial Consortium  
(OGC), all of which are in wide use.

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.

REFERENCES

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-063 and LBNL-1779E.]. (Identified in this  
charter as OpenADR (Version 1.0))

(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, Associate
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
Bob Stayton, bobs@sagehill.net, Associate
Mike Truskowski, truskows@cisco.com, Cisco Systems Inc.
Matt Wakefield, mwakefield@epri.com, Electric Power Research Institute


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

(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. The direct link to the document is http://drrc.lbl.gov/openadr/pdf/CEC-500-2009-063.pdf 
.

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








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