[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Energy Interop Resources
Bruce is right. We are playing word substitution here – but then, that is the semantic challenge. For the word resources: If we want to get to pieces of equipment that can be described in the language of Generation, resource using the semantics from the EMIX Resource is a natural. From the perspective of the central operator, a catalogue of resources makes solid ontological sense. Against the word Resource: As we move up recursively through VTNS, the Suite VTN, the Building VTN, the Office Park VTN, the Aggregator VTN, the RTO VTN, the things that are “activated” look less and less like physical things. To the VEN, being a Resource is slightly better, I guess, then being Load. To the VEN, it is not clear that the Resource terminology makes sense. In the EPRI paper, there is no concept of anything remotely like a resource. This does not mean they are wrong, but it does suggest we should be cautious as to how we expand the valence of a VEN. If the choice is add resources we must be clear that (1) these are not exactly the same as defined in EMIX RESOURCE.XSD. Nodes: I am personally not fond of the Node name. Somehow an End Node, virtual or not, should not have Nodes beyond it. Still, I could live with either one. Any other suggestions, anyone? Here are some of my favorite pre-existing Virtual End Nodes (VENS) http://www.thecenter2000.com/last/ http://mdesmond.com/index.php?id=endoftheinternet http://www.the-last-page.com/ "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you." - Fredrich Nietzche
From: Horst, Gale [mailto:ghorst@epri.com] I like where this is going with the definitions offered by both Toby and Bruce. Perhaps it makes the VEN a bit more flexible in that it could, optionally, enroll several nodes. But this probably doesn’t break the rules of the architecture since, as Toby noted, “ The VTN has no direct interaction with these Nodes”. Would a battery, as an example, be registered as more than one node? Curtailable load (e.g. charging), Energy Supply (discharging) or are both of these chacteristics in the same enrollment? Gale R. Horst Electric Power Research Institute (EPRI) From: Bartell, Bruce [mailto:bbartell@xtensible.net] OK I get it. This is a word substitution game. “A Virtual End Node may choose to enroll a single node.” I think a VEN registers or enrolls (don’t care which one we pick) the Resource. The Resource is the dispatchable entity that can deliver on the promise to shed load or generate power. These are what I think of as products (or maybe just one if we consider resources that can do both and can make the choice). I have thought of the Nodes as the proxy or even just a URI location for the interaction. If we go back to the original REC definition (Resource Energy Controller) that became VTN; it is a controlling entity. The resource is the dispatchable entity that is an aggregation of the capabilities of a group of assets or resources and under the control of a VEN. From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] Well let’s try it out…..as they are created during Enrollment: Enrollment and Withdrawal of ResourcesA VEN MAY choose to enroll a single Node, and reveal no information about its internal systems. A VEN may have no Nodes. Some markets may require that all participants Enroll, even if they are able to provide no Nodes. A VEN may enroll new Nodes and withdraw other Nodes. Having withdrawn its Nodes, a VEN may again have no enrolled Nodes. A VEN with no Nodes is unable to participate in VEN-VTN based markets. It is not in scope to define the market rules for VENs without Nodes Resources as Distinguishable ProductsDuring enrollment, a VEN may choose to register one or more products with the VTN. These products are known as Nodes. The VTN has no direct interaction with these Nodes. As in a restaurant, wherein the customer may request published menu items from the waitress, the VTN may transact for published Nodes 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 Node, or to request Nodes that are not registered. The products represented by the Nodes may be distinguished by any number of characteristics. EMIX product definitions are distinguished by attributes that include schedule, location, and source and responsiveness. The products represented by EI Nodes may be as concrete as an industrial stone crusher or as abstract as an aggregator’s product: “Air Conditioning for the Elderly”. A Node 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, but any external communication is through the VEN. A VEN may even wish to register Nodes 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 Nodes are registered by the same VEN. EI does not require that all load controlled by a VEN be indicated in Nodes. There may be market rules that require such “full registration” for all participants, but EI does not. Node as used there gives me some heartburn, but if the TC as a group likes that (sing out here/now) I can write it up that way… Somehow Node bothers me when presented by an Aggregator….that and the whole argument reads like a treatise on Lymphoma… "It is the theory that decides what can be observed." - Albert Einstein
From: Bartell, Bruce [mailto:bbartell@xtensible.net] 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. From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] 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
From: Anne Hendry [mailto:ahendry@pacbell.net]
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 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
Gale R. Horst Electric Power Research Institute (EPRI) From: Anne Hendry [mailto:ahendry@pacbell.net] 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: Where it gets sticky is that EMIX never does define the term 'Resource'. Resources are a means of providing products. (meaning, to me, a way of supplying the core ingredient with which to create a product) 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). 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.
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
From: Ed Cazalet [mailto:ed@cazalet.com] 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 From: Considine, Toby (Campus Services IT) [mailto:Toby.Considine@unc.edu] 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 ProductsDuring 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 ResourcesA 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 RequirementsSome 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"
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]