I disagree that each EMIX product needs a ramp
component. Some EMIX product may
have a ramp component.
A good example is bidding into ISO markets. The ISO accepts multi-part bids from
generators and dispatches them,
Part of the bid is a ramp rate curve vs. MW output
(not a WS-calendar construct ). The
output of the ISO process is hourly and five minute schedules for the
generator, without any explicit WS-Calendar-like ramp. Yes the generator does not move instantly
from the level in one interval to the next in a step, but the balancing
processes of the ISO accommodate this.
Most forward wholesale contracts may be
scheduled hourly. Ramping up and
down from levels in one hour to next often has an assumed ramp ( from 10
minutes before the hour to 10 minutes
after the hour). As Phil has said, a registration process can deal with any
standard ramp assumptions. For
financial contracts the ramp can be ignored.
In automated markets it is easier to deal with
schedules where the ramp is a characterized by series of shorter interval schedules. It is also how we meter delivery as
energy over an interval. This
provides standard products and contracts in each interval. If every offer has a different ramp rate
on each end markets it is harder to get liquid markets.
Also, think of the complexity in adding up a
large portfolio of schedules each with a different embedded WS_Calendar
ramp rate. The final schedule with
include all of the ramps, all with different durations and start times. It is much easier to do what we do today
which is a sequence of yearly, monthly, daily, hourly, 5 min schedules each of
which are simple block schedules, transactions, or offers.
Edward G. Cazalet, Ph.D.
101 First Street, Suite 552
Los Altos, CA 94022
650-949-5274
cell: 408-621-2772
ed@cazalet.com
www.cazalet.com
From: Toby Considine [mailto:tobyconsidine@gmail.com] On
Behalf Of Toby Considine
Sent: Tuesday, September 14, 2010 12:20 PM
To: emix@lists.oasis-open.org
Subject: [emix] Ramp intervals
Do we need a construction within EMIX for ramping intervals?
I am tieing this to such things as the 3-part generation bids
Consider the case of a long generation cycle followed by a
discrete ramp cycle. The whole shape is the electricity produced. Things
don’t just shut down, there is some electricity that needs to go
somewhere, and if it goes onto the grid, it must be planned for and balanced.
The large rectangle on the left is the scheduled generation
period. The it may be scheduled for three hours, it may be scheduled for 1, it
may be scheduled for 16. The slopey bit on the right just comes along for
the ride.
The shape above is an ugly interval.We could solve it by
making an infinite number of intervals, or at least enough so that we can
assume that each one was flat. I think it would be an error to recreate intro
calculus within EMIX…
WS-Calendar supports separating a scenario like that above,
in which the things are split into two linked intervals. It is easy to schedule
the interval on the left, to any length, It is the supply of a constant amount
of energy for a variable period of time, as per contract. The funny looking
shape on the right, comes along for the ride; buying the left is buying the
right. This occurs in many scnarios in homes / buildings / energy / …
So in Emix, we have a product, and then we have a ramp. The
ramp is a predictable varying, but constant duration (probably) delivery of
product. There may be ramp ups and ramp downs.
We need to include handling of ramped energy in each EMX
product.
“It is difficult to get a man to understand something,
when his salary depends upon his not understanding it” -- Upton Sinclair.
|
Toby Considine OASIS Technical Advisory Board TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech.
Smart Grid Architecture Committee |
|
Email: Toby.Considine@gmail.com http://www.tcnine.com/ |