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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix message

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


Subject: [OASIS Issue Tracker] Created: (EMIX-472) Add information elementto make Tiers actionable


Add information element to make Tiers actionable
------------------------------------------------

                 Key: EMIX-472
                 URL: http://tools.oasis-open.org/issues/browse/EMIX-472
             Project: OASIS Energy Market Information Exchange (eMIX) TC
          Issue Type: Improvement
    Affects Versions: wd30, wd29, wd28, wd27
            Reporter: Toby Considine
            Assignee: William Cox
             Fix For: wd31


Tiers are a confusing, complicated structure that set a-priori bounds that may or may not be useful on decision making for a single day. Maximum Tier Prices may be charged when there is a power surplus, or lowest prices may be available when there is a power shortage. Tiers are ways to reward efficiency in the absence of a smart grid. Perhaps worse, tiers push small electric vehicles out of reach for the lower income houses that tiers are meant to help. An inner city "golf cart" might be an ideal low-priced EV. Charging one, however, would owner of that EV up the tier structure. Be that as it may, we have been asked to support them.

What we have can adequately describe Tiers. What we have now does not, however, provide actionable information. We talk of installing the new Thermostat, it querying something for the local conditions and prices, and offering the [owner] a UI to manage energy, but based on what? If that Thermostat is installed mid period, there is no way to understand the prices, unless one understands that it is 1 week into the month and you have already used half of the Tier 1 quantity. 

If we ignore ws-calendar components, it looks like this

<xs:element name="accumulation" type="power:AccumulationType"/>
<xs:complexType name="AccumulationType" mixed="false">
	<xs:sequence>
		<xs:element name="accumulationDuration" type = "xcal:DurationPropType"/>
		<xs:element name="accumulationStart"  type="xcal:DurationPropType"/>
		<xs:element name="accumulationQuantity" type="emix:QuantityType"/>
		<xs:element ref="xcal:dtstamp" minOccurs="1"/>
	</xs:sequence>
</xs:complexType>

If we use WS-Calendar properly this is an Event. As of Now here is what the needle reads. If we did that, we would have a 0 duration vevent with a start time of now. We would still need a being and duration in an inner envelope.

As I write this, I have talked myself into an Interval for the Accumulation period. The creation datestamp for that Interval is the time of the reading. The sole payload is the accumulated energy to date.

<xcal:interval>
	<xcal:properties>
		<xcal:uid>
			<xcal:text>ecc4e170-05ed-4e5c-bddf-e0aed662ea92</xcal:text>
		</xcal:uid>
		<xcal:dtStart>2011-05-15T09:00:00</xcal:dtStart>
		<xcal:date-time>2011-05-28T16:15:00</xcal:date-time>
		<xcal:duration>
			<xcal:duration>P1M</xcal:duration>
		</xcal:duration>
		<xcal:x-wsCalendar-attach>
			<emix:accumulation>
				<emix:quantity>135</payload:units>
			</ emix:accumulation >
		</xcal:x-wsCalendar-attach>
	</xcal:properties>
</xcal:interval>



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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