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] Updated: (EMIX-128) Suggest creating examplesof "standard" time intervals for interoperation

     [ http://tools.oasis-open.org/issues/browse/EMIX-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

William Cox updated EMIX-128:

    Fix Version/s: wd16
                       (was: csprd01 Public Review Draft)

> Suggest creating examples of "standard" time intervals for interoperation
> -------------------------------------------------------------------------
>                 Key: EMIX-128
>                 URL: http://tools.oasis-open.org/issues/browse/EMIX-128
>             Project: OASIS Energy Market Information Exchange (eMIX) TC
>          Issue Type: Task
>    Affects Versions: csprd01 Public Review Draft
>            Reporter: Edward Cazalet 
>            Assignee: William Cox
>             Fix For: wd16
> During the 12/17/2010 EMIX workshop meeting we discussed the need to prepare additional examples of the application of EMIX and its use of WS-Calendar. 
> On the customer side of the meter there is a need for intervals with different, flexible definitions to accomodate the needs of each domain. 
> On the grid side there are many applications that use common time intervals to facilitate interoperation.  
> Here are a few examples:
> 1.	Many ISO and wholesale transactions and transmission scheduling are done on hourly intervals that start exactly on the hour and have a duration of exactly one hour.  
> 2.	Residential meters with low bandwidth communication may receive the definitions of the intervals (say 15 minutes) for usage measurement infrequently and then use these standard intervals for communication of usage.measurements without communicating the interval definitions.  
> 3.	An ISO will typically work with hourly, 5 minute, or 4 second intervals (or variations on these) that are nested within each other.  
> 4.	Traders may transact standard blocks of power for all hours of a month, or only certain peak hours of a month that a community of traders or an exchange may agree to.  
> WS-calendar is completely flexible as to start times and duration of intervals, but some specific examples would help us better understand how to apply WS-Calendar and EMIX.
> The grid side of the power industry uses a variety of intervals for interoperation.  The intervals for some transactions are long, perhaps defined in years and months, and some are short, defined in days, hours, minutes and seconds.  Depending on the application the focus may be on long or short duration intervals.
> For convenience and simple interoperation, interval definitions are typically nested.  That is 
> intervals defined in seconds are nested within intervals defined in minutes, 
> that are nested within intervals defined in hours, 
> that are nested within intervals defined in days, 
> that are nested within intervals defined in months, 
> that are nested within intervals defined in years. 
> Below is a sample of nested interval definition choices that might be used in a given market:
> Calendar Year (365 or 366 days)
> Calendar (Single Months, or winter, spring, summer, fall, blocks of months)
> Day (Single day, weekday, weekendday, holiday, set of holidays)
> Hour ( 23,24,or 25 hours per day, or blocks of off-peak , shoulder, peak, superpeak hours)
> SubHour ( 30 minutes, 15, minutes, 10 minutes or 5 minutes)
> Minute ( 60 seconds )
> Sub Minute ( 4 or 6 seconds) (watch out for leap seconds)
> For example, the California ISO 
> 1.	dispatches resources offering frequency regulation every 4 seconds.
> 2.	dispatches real-time energy every 5 minutes
> 3.	settles imbalances with generators and loads every 10 minutes.
> 4.	dispatches some imports and resources every hour
> 5.	accepts offers and dispatches resource for each hour of the next day.
> Note that there are exactly 75 four-second intervals in a five-minute interval, 2 five-minute intervals in a ten-minute interval, 6 ten-minute intervals in an hour, 24 hour intervals in a day, and 365 day intervals in a year ( ignoring daylight savings shifts, leap years and leap seconds for now).
> So it would seem that we should only need to specify nested sets of intervals only once and participants in market might simply point (using a URI) to a standard set of intervals that all of them will use.
> However, we also need to address the interoperation of market that may define intervals slightly differently.  For example, one market may use Eastern time and another may use central time.  Converting hourly and subhourly transactions would present no problems, but transactions defined for days, months and years in the two markets require carefully modeling for interoperation.
> Finally, the examples need to show how WS-Calendar neatly handles time zone differences, day light savings times, leap years and leap seconds and time synchronization and errors.
> However I suggest we start with two simple examples.
> 1.	A standard set of 24 hourly intervals (for day ahead operations) and a single hour intervals (for hour-ahead) for ISO/RTO offers, awards and schedules.
> 2.	A standard set of 15 minute intervals for residential metering and usage communication.
> The examples should produce XML and show how energy, usage and price may be communicated.

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]