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

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

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


Subject: RE: RE: [energyinterop] Proposal for replacement for EI Fig. 1-1


We discussed this at a TC meeting and decided on the NIST  7 domain/cloud diagram.  I was directed to update the document with text to support the 7 cloud diagram and that is what is in the current draft that has been available for a while.

 

Edward G. Cazalet, Ph.D.

101 First Street, Suite 552

Los Altos, CA 94022

650-949-5274

cell: 408-621-2772

ed@cazalet.com

www.cazalet.com

 

From: Girish Ghatikar [mailto:gghatikar@lbl.gov]
Sent: Saturday, May 07, 2011 3:20 PM
To: Holmberg, David
Cc: Ed Cazalet; Phil Davis; energyinterop@lists.oasis-open.org
Subject: Re: RE: [energyinterop] Proposal for replacement for EI Fig. 1-1

 

Hi David, 

 

Did we come to some form of consensus on this? Why can't we just use the 7 domain model of NIST-R 1.0 and define the EI scope? 

Thanks,

-Rish

On Mon, Feb 28, 2011 at 12:39 PM, Holmberg, David <david.holmberg@nist.gov> wrote:

From that perspective (T&D as product) I can make most services into a product, but in my mind T&D is still a service. So, still not clear to me. I guess if we are talking about actors, then the 7 cloud diagram might be right, and which of those clouds are NOT speaking EI for some transaction or another?

 

Thanks,
David

 

From: Ed Cazalet [mailto:ed@cazalet.com]

Sent: Friday, February 25, 2011 8:56 PM
To: Holmberg, David; 'Phil Davis'

Subject: RE: RE: [energyinterop] Proposal for replacement for EI Fig. 1-1

 

EMIX provides for T&D (Transport) to be transacted much like energy is.  The idea is that a customer party buys at wholesale (where permitted) and then buys a Distribution Transport product to get it to his business.  Or he could buy from a generator at wholesale and then buy Transmission and then Distribution Transport products as three transactions.  Or he may buy from a retailer who buys the energy, transmission and distribution products and then sell a bundled product to the customer.

 

EI has not emphasized this capability, but it is inherited from EMIX. Since Transport and Energy are both products in this model putting Transport (T&D) in the Service Provider Cloud is like putting generation resources in the Service Provider Cloud. So this is a reason to keep T&D distinct from Service Providers.

 

I think the clouds at this level should be the 7 NIST Clouds or the 5 Cloud Diagram you developed that combines T&D in a Cloud and Markets and Service Providers in a Cloud.  I do not think we should introduce concepts such as Curtailment Resources at this level in the report because the TeMIX implementation of Transactive Energy does use curtailment or model curtailment as a resource.  OPENADR does  use Curtailment Resources, for example.  So this concept should be introduced later in the document after we make distinctions between the two approaches.

 

These distinctions among the models are important to keep clear.  This does not mean we need to be strong advocates in the report of one model or the other.  But the distinctions will help us to better communicate the flexibility and usefulness of EI in many applications.

 

Edward G. Cazalet, Ph.D.

101 First Street, Suite 552

Los Altos, CA 94022

650-949-5274

cell: 408-621-2772

ed@cazalet.com

www.cazalet.com

 

From: Holmberg, David [mailto:david.holmberg@nist.gov]
Sent: Friday, February 25, 2011 12:33 PM
To: Phil Davis
Cc: Ed Cazalet; energyinterop@lists.oasis-open.org
Subject: RE: RE: [energyinterop] Proposal for replacement for EI Fig. 1-1

 

T&D is its own domain in the NIST cloud diagram, but isn’t it actually the ISOs and utilities and independent distribution operators that run the grid? They are providing a service to move power, charging back to the utilities or markets. So, my lumping them in with service providers seems appropriate. Likewise we have consumers (the loads plain and simple) and we have energy resources (generation, storage, load curtailment, wherever it is on the grid or facility domain). Markets could be viewed as a service provider, but they are a key part of Energy Interop, so I’d like to keep them in a separate cloud, so I would like to propose the following slightly revised 4 cloud picture and would like to hear what our esteemed editor thinks about this discussion (although I welcome anyone’s comments on this).

 

Which, interestingly, is back where we started, except now “generation” is “energy resources”:

 

 

Thanks,
David

 

 

From: pddcoo@gmail.com [mailto:pddcoo@gmail.com] On Behalf Of Phil Davis
Sent: Wednesday, February 23, 2011 4:05 PM
To: Holmberg, David
Cc: Phil Davis; Ed Cazalet; energyinterop@lists.oasis-open.org
Subject: Re: RE: [energyinterop] Proposal for replacement for EI Fig. 1-1

 

If we separate 'D' from 'utility', what does a utility do?

Phil Davis
Swyped via Android

On Feb 23, 2011 3:57 PM, "Holmberg, David" <david.holmberg@nist.gov> wrote:
> I'm starting to think that our original figure was fine. Can't we say that T&D is a service provider, serving utilities? In the text we can explain what each cloud includes:
>
> 1. Market operators--ISO, utility, microgrid, etc
>
> 2. Service providers--energy service, DR, aggregation, facility energy management, T&D, etc
>
> 3. Generation-this is large generation as well as DER on the grid side and in the facility: curtailable load, generation, and storage
>
> 4. Customer-this is strictly the load, while a customer may also provide DER/generation services.
>
> If we add a T&D cloud, that can be fine too-just looks more like the NIST cloud diagram.
>
> David
>
> From: Ed Cazalet [mailto:ed@cazalet.com]
> Sent: Tuesday, February 22, 2011 5:32 PM
> To: 'Phil Davis'; Holmberg, David
> Cc: energyinterop@lists.oasis-open.org
> Subject: RE: [energyinterop] Proposal for replacement for EI Fig. 1-1
>
> The text from the draft that puts this Figure into context follows:
>
> 2 Energy Interoperation defines information exchanges and services to coordinate energy supply and use,
> 3 including power and ancillary services, between any two parties such as energy suppliers and customers,
> 4 markets and service providers indicated below. Energy Interoperation makes no assumptions about
> 5 which entities will enter those markets, or as to what those market roles will be called in the future. Energy
> 6 Interoperation supports each of the arrows that represent communications, but is not limited to those
> 7 interactions.
> 8
> 9 Figure 2-1: Representative Communications for Energy Interoperation
> 10 Energy Interoperation defines messages to communicate price, reliability, and emergency conditions.
> 11 These communications can concern real time interactions, forward projections, or historical reporting.
> 12 Energy Interoperation is intended to support market-based balancing of energy supply and demand while
> 13 increasing fluidity of contracts. Increasing deployment of distributed and intermittent energy sources will
> 14 require greater fluidity in both wholesale and retail markets. In retail markets, Energy Interoperation is
> 15 meant to support greater consumer choice as to energy source.
>
> The public comment suggested only that we add a cloud representing T&D. We should also at a reference to T&D in the text above.
>
> The issue of what roles the parties play ( buyer/seller or VTN/VEN or DR or DER provider) are addressed later in the document.
>
> I vote for adding the T&D cloud to the original diagram. The points raised by David and Phil are valid but they can delt with later in the document.
>
>
> Edward G. Cazalet, Ph.D.
> 101 First Street, Suite 552
> Los Altos, CA 94022
> 650-949-5274
> cell: 408-621-2772
> ed@cazalet.com<mailto:ed@cazalet.com>
> www.cazalet.com
>
> From: pddcoo@gmail.com [mailto:pddcoo@gmail.com] On Behalf Of Phil Davis
> Sent: Tuesday, February 22, 2011 2:12 PM
> To: Holmberg, David
> Cc: energyinterop@lists.oasis-open.org
> Subject: Re: [energyinterop] Proposal for replacement for EI Fig. 1-1
>
> With Dave;s comments, I like the three node model (no consumer) better for purposes of this discussion. Also, would the NERC idea of Balancing Authority work to replace the Market Operator term with all its components? It conveys a sense of responsibility regardless of the title of the entity.
>
>
> Phil Davis | Senior Manager - Solutions | Schneider Electric Demand Response Resource Center | 3103 Medlock Bridge Road, Suite 100 | Norcross, GA 30071 | 404..567.6090 | phil.davis@us.schneider-electric.com<mailto:phil.davis@us.schneider-electric.com> | www.schneider-electric.com<http://www.schneider-electric.com> | Skype: pddcoo
>
> On Tue, Feb 22, 2011 at 5:03 PM, Holmberg, David <david.holmberg@nist.gov<mailto:david.holmberg@nist.gov>> wrote:
> Good question. Is not Energy Interop serving the ideal of more efficient markets and use of resources? So, the "Resouce Provider" can be the customer, or the generator, or the storage-but then maybe they are also just a service provider to the utility? That is, OpenADR is not serving a customer, but rather the "customer" is providing DR service to the utility. Maybe EI is only about VEN and VTNs? And the market operator is a "market service provider"? If by customer we mean the end load buildings that consume most of the power and the industrial plants that eat the rest, then they are the only ones who are not a service provider, just a consumer (although they can act in other roles). So, maybe we need a cloud just for "consumer"? I was trying to show that the consumer can also be DER. Maybe this?
>
> [cid:image001.jpg@01CBD371.63465530]
>
> From: Ed Cazalet [mailto:ed@cazalet.com<mailto:ed@cazalet.com>]
> Sent: Tuesday, February 22, 2011 4:47 PM
> To: Holmberg, David; energyinterop@lists.oasis-open.org<mailto:energyinterop@lists.oasis-open.org>
> Subject: RE: [energyinterop] Proposal for replacement for EI Fig. 1-1
>
> Sorry, but where is the customer in the new diagram? Are they not who Energy Interop is to serve?
>
> Edward G. Cazalet, Ph.D.
> 101 First Street, Suite 552
> Los Altos, CA 94022
> 650-949-5274
> cell: 408-621-2772
> ed@cazalet.com<mailto:ed@cazalet.com>
> www.cazalet.com<http://www.cazalet.com>
>
> From: Holmberg, David [mailto:david.holmberg@nist.gov<mailto:david.holmberg@nist.gov>]
> Sent: Tuesday, February 22, 2011 1:42 PM
> To: energyinterop@lists.oasis-open.org<mailto:energyinterop@lists.oasis-open.org>
> Subject: [energyinterop] Proposal for replacement for EI Fig. 1-1
>
> This addresses Jira issue 306.
>
> The current Fig 1-1:
> [cid:image002.jpg@01CBD371.63465530]
>
> My proposed update for discussion:
> [cid:image003.jpg@01CBD371.63465530]
>
>
> I'm trying to get down to the fundamental view of who is using EI, and away from the NIST cloud diagram. Does this work? Or is it getting closer?
>
> David Holmberg
> NIST Engineering Laboratory
> 301-975-6450
>
> "God cannot give us a happiness and peace apart from Himself, because it is not there. There is no such thing."
> C.S. Lewis
>
>
> ________________________________________________________________________
> This email has been scanned for SPAM content and Viruses by the MessageLabs Email Security System.
> ________________________________________________________________________
>
>
>
> ________________________________________________________________________
> This email has been scanned for SPAM content and Viruses by the MessageLabs Email Security System.
> ________________________________________________________________________




--
Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
GGhatikar@lbl.gov | +1 510.486.6768 | +1 510.486.4089 [fax]

This email is intended for the addressee only and may contain confidential information and should not be copied without permission. If you are not the intended recipient, please contact the sender as soon as possible and delete the email from computer[s].



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