[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emix] Plane of Control vv. Transactional Energy
David That user interface, the policy framework of “the director’s bowling league” is entirely out of scope. Dave’s conversation was a follow on to today’s working meeting. TO frame it: - Microgrid is an entity responsible for managing its energy use, storage, generation and energy market operations. - If there are market operations on a Microgrid, then the market interface is the ESI (Energy Services Interface) - An entity outside the microgrid does not concern itself with the activities inside the microgrid except to the extent that they create services (deltas in energy used or produced) that can be offered up to the market interface (ESI). - Microgrids can contain microgrids and be contained in microgrids. An office park could be a microgrid containing office buildings each of which is a microgrid. - Any system might be a microgrid operating through an ESI. A washing machine can receive prices and price projections within the house; if it does so, it does so through an ESI. - The inside of a microgrid is a market that may or may not have any similarities to the outside market. It may use different currencies, impose surcharges, whatever. Those decisions are all outside of scope There is no assumption that the “inside” of an ESI looks like the outside. An ESI can be thought of as a secure gateway. It decides what messages get passed through. An off-grid building may have not external ESI, yet communicate with any number of contained systems which have an ESI on the outside. Within a microgrid, systems may bid for the power from the solar panel. The ESI of the microgrid may only let external power in when certain characteristics (price, source, location, high priority request from a component microgrid, whatever) are met. The internal market allocate the available energy / clear that market. This is the discussion that led to discussion of the ESI as a “plane of control”. The internal operations of a microgrid, whether it is fan operation in the HVAC microgrid, the motor operation of the washing machine microgrid, or the HVAC system operation on Building microgrid out of scope from outside of each of the respective the ESIs – only their energy results flows out. Within a microgrid, the system may choose to use any strategy it wants. I may have no internal microgrids in a house and do direct load control of all other systems in the house from the [smart thermostat]—and that control is out of scope. I may choose either BACnet or LON to run the HVAC microgrid in the commercial building, and those decisions would be out of scope for the building microgrid. Within the microgrid, I may choose to augment market operations with direct control, just as you may choose more intimate relationships between the people in your house than we allow on the street. In that case, I *could* create a policy structure to support the director’s bowling alley. That *could* be by direct control. It *could* be by using oBIX as augmented by WS-Calendar to inform the Alley of how aggressively to bid for energy. All of those are indeed out of scope for EnergyInterop. Anything beyond price and product is out of scope for EMIX. And the Human Interface is outside the scope of them all… This whole thread is bleed-through from EnergyInterop to EMIX. tc "If flies are allowed to vote, how meaningful would a poll on what to have for dinner be, and what would be on the menu?" - Unknown
From: David RR Webber (XML) [mailto:david@drrw.info] David / Toby, Beware of ocean boiling!!! In my experience building intelligent expert systems - there are a slew of potential inputs and sources of control information and rules. Within OASIS though - all we can do is focus on core concepts and build that. I'm sure implementers will find all kinds of value-add features for their products to differentiate themselves in the marketplace. We don't need wire XML formats to support those! As an example look at the OASIS emergency work with the CAP spec'. That is incredibly simple XML constructs - many argue too simple. Nevertheless - time to market was key for them - so they went with simplest path - and as a result - there is an array of vendors offering all kinds of products - and devices that use CAP messages. I believe that KISS here for V1.0 is also vital. DW <snip>Is the question of “plane of control” the same as “where is the human interface?”, unless (as in the case of the refrigerator) there is no human interface? And in the case of a campus or microgrid there are effectively multiple human inputs that impact a single system. There is the building operator and the human resources office and the Energy management director’s office and the “how green we want to be” CEO office. Each of these impacts decisions about conditions on energy use, and how and when and why. Hopefully they all work together to have a consistent policy for response to price signals and other priorities. It’s the “other priorities” that Toby brought up on the call. Price is not all that matters. Maybe source matters. Maybe local matters—that might be factored in as a price adder on external power. Other priorities might be reflected as exceptions in the policy for a particular system, like “the bowling alley will never go into reduced-power mode when the director has bowling league”.</snip> Thanks, DW
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]