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: [energyinterop] Energy Interop Resources


Node is defined as: 1.A point at which lines or pathways intersect or branch; a central or connecting point

2.A piece of equipment, such as a PC or peripheral, attached to a network

5.(in generative grammar) A vertex or endpoint in a tree diagram

 

Looks like it fits just fine.

 

 

Bruce Bartell

Xtensible Solutions

Mobile: +1.321.258.6500

bbartell@xtensible.net  |   www.xtensible.net


From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Monday, June 20, 2011 9:59 PM
To: energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Energy Interop Resources

 

If the [not a resource] is offered by a high level aggregator, then the word ‘NODE” would be at best, misleading.

 


"It is the theory that decides what can be observed."   - Albert Einstein


Toby Considine

Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

Facilities Technology Office
University of North Carolina
Chapel Hill, NC

  

Email: Toby.Considine@ unc.edu
Phone: (919)962-9073

http://www.oasis-open.org

blog: www.NewDaedalus.com

 

 

From: Anne Hendry [mailto:ahendry@pacbell.net]
Sent: Monday, June 20, 2011 6:54 PM
To: Horst, Gale
Cc: energyinterop@lists.oasis-open.org
Subject: Re: [energyinterop] Energy Interop Resources

 

> We are looking for a word, that MAY be “resource” for these things. 

We could stick with consistent terminology and call it a “node” or “electricity node” that refers to a communicating entity that represents a device, devices, or system that consumes or produces electricity.  I suppose it would be easier to call it a resource, if that term had not already been over-used and confuscated.  ;)

If we define it clearly it should be alright. There are only so many words in the English language and we're committed to it! Talking about 'electricity node', or, from Jerry, 'power system' or 'energy system', could collapse to
- energy resource
or
- energy node
or
- power resource

I'm still partial to 'resource' over 'node' and think it could stand on it's own with a proper and clear definition.

-A

Horst, Gale wrote, On 6/20/2011 1:39 PM:

Anne:

 

The first three look reasonable to me.  But the addition of the adverse circumstances part seems unnecessary and adds a dimention that could be too specific.

 

Cheers,

Gale

 

  • Any physical or virtual entity of limited availability that needs to be utilized to obtain benefit from it.
  • An economic or productive element required to accomplish an activity
  • A source of supply that can be drawn on when needed
  • An asset with attributes and capabilities that can be drawn upon in adverse circumstances

 

 

 

Gale R. Horst

Electric Power Research Institute (EPRI)
942 Corridor Park Blvd.
Knoxville, TN 37932
Office: 865-218-8078
Cell:   865-368-2603

ghorst@epri.com


From: Anne Hendry [mailto:ahendry@pacbell.net]
Sent: Monday, June 20, 2011 4:00 PM
To: Considine, Toby (Campus Services IT)
Cc: Ed Cazalet; energyinterop@lists.oasis-open.org
Subject: Re: [energyinterop] Energy Interop Resources

 

The EI spec does state that it does not define Resource, that Resource is defined by EMIX.  That language could be aligned/clarified a bit more but excerpts from EI wd23:

Line 608:
Energy Interoperation uses EMIX to describe the energy resources and products that are contained within the WS-Calendar intervals.
Line 665:
The EMIX Resource describes a service that could be brought to market.
Line 722:
The Resource terminology and the duality of generation and curtailment are from [EMIX].
Line 938:
Entity: Resource
Name: resource
Description: An EMIX Resource with additional information
Definition: A Resource including performance envelope and additional information including Resource Name

Glossary, Line 1454:
Resource (as defined in EMIX): A Resource is something that can describe its capabilities in a Tender into a market. How those Capabilities vary over time is defined by application of the Capability Description to a WS-Calendar Sequence. See [EMIX].
Glossary, Line 1450
Resource (as used in Energy Interoperation): a Resource is a logical entity that is dispatchable. The Resource is solely responsible for its own response. A resource description specifies the performance envelope for a Resource. If a Resource can participate in multiple markets, it may have multiple desriptions.

Where it gets sticky is that EMIX never does define the term 'Resource'.

There are Resource 'Operation Descriptions', 'Offer Capabilities', and 'Resource Types', but the actual definition of a Resource is not stated .  ResourceType is also not defined in the spec.  There is a UML diagram 'Summary of ResourceTypes' (13.9) which shows the enumeration of ResourceDescriptionType, not ResourceType.  So we could possibly use more descriptive text for that EMIX section or prior.

We had originally, in EMIX, tried to find a word for a single unit of the 'basic thing' that was being bought/sold/offered.  The word we came up with (borrowed from eCommerce) was "Item".  There is an Item base, which then gets paired with 'quantity' to produce a 'product description'.

ResourceDescription is an extension of ProductDescription (with added mrid, emixInterface, and Terms) so ProductType seems to be defined first, then ProductDescription, then ResourceDescription from it.  The assymetry is that while there is a ProductType defined, there is no analogous 'ResourceType' defined (the missing piece), only the enumeration. 

So EMIX doesn't define a 'resource', per se, simply its capabilities, its use, and types (below).

In EMIX there was recently a discussion of 'product' and 'product differentiation' which has made its way into this discussion so perhaps continuing the discussion on the EMIX side would help bring it to conclusion here as well.

EMIX resource.xsd:
<xs:simpleType name="ResourceTypeEnumeratedType">
<xs:restriction base="xs:token">
<xs:enumeration value="dispatchableHydro"/>
<xs:enumeration value="nonDispatchableHydro"/>
<xs:enumeration value="windGeneration"/>
<xs:enumeration value="solarGeneration"/>
<xs:enumeration value="tollingContract"/>
<xs:enumeration value="aggregateResource"/>
<xs:enumeration value="dispatchableStorage"/>
</xs:restriction>
</xs:simpleType>

It's my understanding/expectation that a VEN and Resource are not the same thing.  That a VEN can represent multiple resources (that additional level of detail to the diagram we were talking about last week).  Keeping in mind

Resources are a means of providing products.

(meaning, to me, a way of supplying the core ingredient with which to create a product)
then products and resources are also not the same thing.
I don't view Products as being "represented by Resources".
My understanding is almost the opposite: resources are presented as products once all their characteristics and capabilities are communicated.

So for instance, I would change the statement below from

a VEN may choose to register one or more products

to

a VEN may choose to register one or more resources (speaking from the end not point of view now)

meaning, on the resource (eg. say a generator) side of the VEN, the VEN is taking registration requests.  In the simple scenario it is not until those capability registrations are assimilated by the VEN and presented to the world on the other side of the VEN for consumption that they become products.  So a generator is a resource.  It can register it's capabilities/characteristics/constraints with a VEN which presents that bundle, as a product, to the VTN (world on the other side of the VEN from the resource).

I would scratch this sentence altogether:

These products are known as Resources.

I don't think we need another word/term.  I think 'Resource' is just fine if we can agree on its definition and use it consistently.

I think part of the problem is that the way schema inheritance is working it appears the logical opposite.  The other part of the problem is that no matter how it's written, the English language and individual parsing of words and sentences can make even what appears to one person to be crystal clear, mean completely the opposite to the other person!

That said, here are my contributions to a definition of Resource:

  • Any physical or virtual entity of limited availability that needs to be utilized to obtain benefit from it.
  • An economic or productive element required to accomplish an activity
  • A source of supply that can be drawn on when needed
  • An asset with attributes and capabilities that can be drawn upon in adverse circumstances


or any combination of above.

-A


Considine, Toby (Campus Services IT) wrote, On 6/20/2011 8:03 AM:

Well, as you logged in Jira the other day, the use of the Word Resource in EI is different than the use of the word Resource in EMIX

 

I am open to

 

Suggestions for naming this thing. (“Guava”)

Words to use for non-recursive definitions of the “Guava”

Tc

 


"It is the theory that decides what can be observed."   - Albert Einstein


Toby Considine

Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

Facilities Technology Office
University of North Carolina
Chapel Hill, NC

  

Email: Toby.Considine@ unc.edu
Phone: (919)962-9073

http://www.oasis-open.org

blog: www.NewDaedalus.com

 

 

From: Ed Cazalet [mailto:ed@cazalet.com]
Sent: Monday, June 20, 2011 11:00 AM
To: Considine, Toby (Campus Services IT); energyinterop@lists.oasis-open.org
Subject: RE: [energyinterop] Energy Interop Resources

 

Some suggestions.

 

Let’s not use the term “products” for “resources” .  Resources are a means of providing products.  A VTN may purchase the right to use a VEN resource capability to produce energy products.

 

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: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu]
Sent: Monday, June 20, 2011 7:17 AM
To: energyinterop@lists.oasis-open.org
Subject: [energyinterop] Energy Interop Resources

 

As requested, a preliminary write-up of our Resource discussions. For comments, please use the numbered PDF.

 

Thanks

 

tc

 

Energy Interop Resources

(which may, as Ed Cazalet suggested, be misnamed)

As defined in the EPRI white paper, all interaction is between the VEN and the VTN. Neither the VEN or the VTN can interact through the other or see past the other. EI is symmetric, in that a given VTN-VEN pair could swap rules for a different market interaction. EI is recursive, in that a VEN MAY be the interface to a microgrid that is itself managed by the VTN-VEN interactions of EI; in that internal market the system which exposes a VEN interface to the outside world may expose a VTN interface.

 

The inner workings of the “internal” microgrid might be by BACnet, or by LONTalk, or by OPC, or by SEP, or by KNX, or by any mix of open and proprietary protocols. The “internal” microgrid might be a municipal utility, an office park, or an industrial site that manages its internal energy using Energy Interoperation. Whatever the communications and interactions of the internal grid, the direct interactions through the exterior-facing VEN are the same: none.

Resources as Distinguishable Products

During enrollment, a VEN may choose to register one or more products with the VTN. These products are known as Resources. The VTN has no direct interaction with these resources. As in a restaurant, wherein the customer may request published menu items from the waitress, the VTN may  transact for published resources from the VEN. Just as the customer is not allowed to fetch food from the kitchen, nor to order off menu meals, so the VTN is not able to interact directly with the systems that underlie each resource, or to request resources that are not registered.

 

The products represented by the resources may be distinguished by any number of characteristics. EMIX product definitions are distinguished by attributes that include schedule, location, and source and responsiveness. Investopedia defines product differentiation thus:

 

It may be as simple as packaging the goods in a creative way, or as elaborate as incorporating new functional features. Sometimes differentiation does not involve changing the product at all, but creating a new advertising campaign or other sales promotions instead.

 

The products represented by EI Resources may be as concrete as an industrial stone crusher or as abstract as an aggregator’s product, “Air Conditioning for the Elderly”. A Resource may be able to respond both up and down, as can a domestic water heater, or have unidirectional gradations of response, as might a thermostat. A VEN may even wish to register Resources for which no response is possible, say, at-home medical equipment.

 

EI makes no assertion as to what might distinguish two products or as to why different resources are registered by the same VEN. EI does not require that all load controlled by a VEN be indicated in resources. There may be market rules that require such “full registration” for all participants, but EI does not.

Enrollment and Withdrawal of Resources

A VEN MAY choose to enroll a single Resource, and reveal no information about its internal systems.

 

A VEN may have no Resources. Some markets may require that all participants Enroll, even if they are able to provide no resources. A VEN may enroll new Resources and withdraw other Resources. Having withdrawn its Resources, a VEN may again have no enrolled Resources. A VEN with no Resources is unable to participate in VEN-VTN based markets. It is not in scope to define the market rules for VENs without Resources

Ancillary Reporting Requirements

Some markets may have reporting requirements beyond those defined in Energy Interoperation. Energy Interoperation neither requires these requirements, nor supports them. Examples of such requirements discussed in the Committee include:

 

Nameplate information for exact identification of assets behind each Resource

Location information to identify local distribution effects of Resources exposed by a single VEN that are distributed geographically (if allowed).

Customer information to enable a third party to audit the market and determine if a single Resources is being sold multiple times

Demographic information about the people represented by each VEN.

All such information is outside the scope of Energy Interoperation. To the extent that participant business rules or market rules requires this information, Energy Interoperation will support this requirement, but it will not include or enforce these requirements. (Perhaps this means that we need to have an approval status on each Resource: Pending, Approved, Refused. Perhaps only Resources approved by the VTN can come to market. If so, that Approval is out of scope; it is merely a reflection of an out-of-band Enrollment.)

 

 


"If something is not worth doing, it`s not worth doing well"
Peter Drucker


Toby Considine

Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

Facilities Technology Office
University of North Carolina
Chapel Hill, NC

  

Email: Toby.Considine@ unc.edu
Phone: (919)962-9073

http://www.oasis-open.org

blog: www.NewDaedalus.com

 

 



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