[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [energyinterop] Numerous questions on Assets and Resources
We agree that like DR, assets are a symptom of the deficiencies in the current market rues and market communications. In an idealized TEMIX world, neither would exist. Even so, it is likely that they will exist as a transition approach for some time. In EMIX, Resource Descriptions merely describe the capability and characteristics of what a [device/system/end node/aggregator/] could do, I terms of energy effect. As you observed in the last meeting, most nodes are price takers. I suppose we could rename Resources to Capabilities to end confusion. I would be happy to entertain that proposal or something similar. As to Resources / Assets as described in OpenADR / EI, those are out of scope for EMIX. tc "It is the theory that decides what can be observed." - Albert Einstein
From: Ed Cazalet [mailto:ed@cazalet.com] The terminology of Resources and Assets is fine for central and distributed generation assets. However, customers use electricity powered devices to provide services. Generally customers don’t want to be thought of as Resources where their devices are Assets to the utility. Only in the world where power is sold a flat, full-requirements rates without interval metering is there a possible incentive for a utility and regulatory body to create NegaWatt-like DR programs. In that case a set of customer devices are called assets and a collection of assets managed by an aggregator is called a Resource. Therefore in EMIX and EI the terms Assets and Resources under the TeMIX profile should apply only to generation devices and not to customer service devices. Within the TeMIX profile there are no DR programs. Instead TeMIX provides a mechanism for both customers and suppliers to enter into forward and spot transactions with optionality for reliability, risk management and other personal and social goals. In my opinion, The Smart Grid should provide prices-to-devices so that the self-management of these devices will allow millions of HVAC units, electric water heaters, pumps, stationary and vehicle battery chargers and other customer devices we don’t even know about to respond in seconds to any situation as they can or cannot. No need to dynamically register these devices with the utility or aggregator. The devices only need to discover the price signals. Without registration and event-based control, everything gets simpler, faster, better, fairer, less subject to manipulation and more consumer friendly. Under a OpenADR and ISO/RTO DR profile the terms Assets and Resources should be applied to both generation and customer service devices registered in a DR program. Edward G. Cazalet, Ph.D. 101 First Street, Suite 552 Los Altos, CA 94022 650-949-5274 cell: 408-621-2772 From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine There are a series of overnight comments on the confusion of Resources and Assets and the slightly different ways these words are used in EI and in EMIX> In EMIX, a Resources is something whose response on energy markets can be described. It can respond this fast, it will have this sorts of response times, it will need to recover for so long before being called again, etc. It is not clear to me that an objects resource description varies whether the description is for a large generator, for small systems described by ASHRAE SPC201, an aggregate response from a commercial building, or from an ASP, or from a REC. In OpenADR, there are the twin concepts of Resource and Asset. A Resource is something that has an OpenADR client. If that client chooses to reveal granular access to its internal systems, then those are termed Assets. There are some OpenADR Resources that are all Asset. Access to an Asset teeters on a the edge of direct load control, and local control that is able mediate access to an Asset through Opt Out messages. The roadmap writes of the Energy Services Interface (ESI) and that there is no direct interaction across the ESI. This is consistent with a rough cut that the ESI is used to interact with a Resource, and that a Resource may choose to reveal Assets while mediated access to those Assets. Making this more complex is potential multiplicity. A commercial chain may have a single ESI revealing many Resources. This sounds at first like a violation, but does not actually violate the model above. It merely pushes the bar to say that a VEN has an ESI in front of One-to-Many Resources, each of which may reveal Zero-to-many Assets. It could be argued that instead that the commercial chain has a single ESI revealing many VENs, each of which fronts a Resource which may reveal Zero-to-many Assets. Whichever of these models we choose, we need to review all services to make sure that they consistently handle the multiplicity of unity of resources in a VEN. But what is an Asset? I think it is a Resource that does not have its own VEN/ESI. (This must be defined carefully to not exclude the commercial chain, as above). At its simplest, an Asset is a Resource contained within a VEN that is exposed. The microgrid within a VEN may have many internal Resources, but opt to reveal just a few of them as Assets. I think it is important that we not limit Assets to simple devices. If the quintessential Asset is the Hot Water Heater, simple, dumb, and with a virtual on/off switch, there is no reason that an apartment building could not expose one hundred hot water heaters as a single large virtual Asset. There is also no reason that a commercial chain should not expose a rolling HVAC set-back across a dozen stores in a ServiceArea as a single Asset. An ASP, of course, could do the same; there is no reason that a demand aggregator could not have a single ESI for a region, but expose certain large Assets of its customers, as Assets in its own interactions upward. This leads back to some interesting questions on registration. Let’s assume a planned, non-emergency situation of a substation renovation during the summer causing a congestion throttle for a neighborhood that will lead to predictable DR events every afternoon during the construction schedule. It seems that an ASP should be able to go in and sign up customers in that defined area, install an ESI on each, and market their response back to this location-restricted time-limited response market. Some of ASP’s resources would choose to expose Assets. The ASP might want to expose/proxy those Assets (or aggregate them into several virtual Assets), and register each as being part of that Service Area. Is this registration encompassed within EI? Now re-do the exercise with dynamic registration in real time after the run-away truck crashes into the substation… This pondering leads me to: Assets are Resources with predictable participation and response that are internal to a VEN, and that the VEN chooses to expose to interaction with or monitoring by the VTN. Assets are described as are any other Resource. “It is difficult to get a man to understand something, when his salary depends upon his not understanding it” -- Upton Sinclair.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]