Raw notes on this discussion at the TC meeting. Actions not defined yet.
Thanks!
bill
--
William Cox wrote:
4A954BC7.6070305@CoxSoftwareArchitects.com" type="cite">These are a few notes on semantic and modeling issues.
This is
background for agenda item 3 today. Specific work items are discussed
below.
Agenda:
3. Discussion on information models, exactly-one and implicit
relationships, and definitions of programs/terms and conditions. (Bill
Cox) Please have available the following documents:
(a) CEC Report PDF
http://www.oasis-open.org/committees/download.php/33260/cec-500-2009-063.pdf
(b) Committee Draft 01 (PDF in
http://www.oasis-open.org/committees/download.php/33627/energyinterop-1.0-spec-wd-01.zip)
I got started thinking about the contractual/terms and conditions model
for "programs", which are often reflected in tariffs. Since tariffs are
a formalization of agreements, and aggregator/facility agreements are
not always reflected in tariffs, without loss of generality (I hope)
I'll use the term "contracts".
Notes with line numbers are to the Committee Draft 01 PDF; notes with
page numbers are to the CEC PDF linked above.
(a) The table on lines 393-400 has no description of programs; in the
CEC document they're in Appendix D (APD-1 et seq, page 149 of the PDF).
The descriptions, or a more general mechanism, will be needed so CD02
holds together better. Evan's email
(http://lists.oasis-open.org/archives/energyinterop/200908/msg00030.html)
on August 13 points this out.
The key issue to me is "how do you define a program"; just as there is
a program reference/name in the schemas in CD01, there is a desciption
and namespace (NOT XML namespace) issue for the names. Should names be
globally unique? That requires a registry and more. Should they be
locally unique? More than one provider can service a geographic area?
One way that uniqueness can be guaranteed is to use a URI; another is a
URN, with the namespace managed by ICANN and registrars, so we don't
have to deal with it. So a pge program might be
"http://www.pge.com/drprograms/CBP".
In passing, the examples in Appendix D all refer to PGE programs.
Surely there are more? We'll need to survey a broader range including
from the ISO/RTO and aggregator perspective.
IN appendix - Ed - fairly representative. California, surveyed
automation, different types of interactions. A lot of work being done
by NAESB and UCA - deliverable for October.
MAP:
T: Is one person likely to have multiple progs applying at one time? DR
program, Energy Storage, Carbon Credit, guy across the street may have
only one.
Ed: Answer is yes. Can of worms, esp with mult progs and providers. Can
be more than one.
T: If I signed up for five levels of DR resp in certain circumstances,
is that one or five programs?
? - 5 programs.
MAP: buildings in multiple progs - CPP, Demand Bidding, priority
required if multiple. Continuously changing rules about whether /what
programs you can participate in.
B: validation on other end.
T: Yesterday thought...if we imagine for a moment that a DR pathway is
the FM channel for DR in california. It could send out 50 prices and
programs, people filter and find the ones that apply to me.
B: Higher uniqueness.
EK: didn't address global namespace issue - makes.
4A954BC7.6070305@CoxSoftwareArchitects.com" type="cite">
(b) A facility has exactly one "uttility" and may participate in zero
or more "programs". If a facility works with one or more aggregators
(for DR or DER), then this model and the schemas appear to break. A
more general model appears to be required.
Following the NYT article that Rish sent to the list
(http://lists.oasis-open.org/archives/energyinterop/200908/msg00040.html,
linking to
http://www.nytimes.com/external/venturebeat/2009/08/14/14venturebeat-power2switch-lets-consumers-choose-their-ele-62417.html
), and looking at the situation as I understand it in Europe and (in
part) Texas, this relationship needs to be explored. What if a facility
can choose among several providers (whether "utilities" or
"aggregators")?
Ed: although didn't use the word aggregator in this way, the model
intended that interaction between participant.
B: architecture drawing - aggregator and microgrids.
4A954BC7.6070305@CoxSoftwareArchitects.com" type="cite">
(c) The "programs" listed reflect those that a real utility apparently
has in place. Are these suitable for standardization, or as a base set
of standardized "programs"?
B: defer until after October deliveries.
4A954BC7.6070305@CoxSoftwareArchitects.com" type="cite">
(d) I hate to say roles and actors (as in the recent email conversation
started by Toby at
http://lists.oasis-open.org/archives/energyinterop/200908/msg00043.html
). But the roles and relationships that are implicit in the CEC and
CD01 versions need to be tackled head on. This is also critical for the
security model (PDF page 129, printed page number 113 in CEC). The
security model needs to be applied to composable fine-grained security
rather than a series of "secure pipes" using SSL (which, incidentally,
was superceded by TLS some years ago). So there's work needed to
develop the relevant security model and policies for CD02.
T: heard two action items - and nobody attached to them.
4A954BC7.6070305@CoxSoftwareArchitects.com" type="cite">
(e) CEC version disclaims any "semantics" (PDF page 22) but describes
"programs" that have specific meaning. We need to resolve that issue.
IMO, the meaning and expected response to the messages is the
"semantics" -- and we need a discussion on this soon. (CD01 on lines
795 et seq discusses "Energy Interoperability Semantics").
B: Semantics of the word "semantics" --
MAP: comment - the moderate and high concepts are related to CPP
tariffs, which have a multiplication factor (3x, 5x). Some customers
respond the same way, some differently. or sustain shed. Also moderate
and high in demand bidding. Similar notion for different programs,
interpreted slightly differently for diff progs.
EK: signals, Low, Moderate, High - user defined semantics for those
signals. Rules in enterprise level def how prices map to those levels.
No global semantics other than what the user/participant d3efines them
to be.
B: signal when sent in context of program.
EK: partially. CPP has natural mappings - 3 levels. Other progs, the
user can define what info from the signal is mapped to a particular
level. That's the level sent. Each participant may use. Config of
utility and facility. E.g. broad example - part prog sends prices. Each
user has a different notion of how a price is mapped into high,
moderate, 15cents might be moderate for user A, high for user B. The
notion of what those levels mean.
B: at the server end - function.
T: Purist price guy, let things sort out. Three levels of response,
that's the only shorthand we have for what we're going to do. A
building doesn't know it can shed 20^ until it tries. Shorthand for how
much DR get, for decision making in the building. Some place (where my
LMH is 7-10-15) and yours is 20-40-50% - based on how we decide to act.
Differs from you go high at 15cents, I go high at 15$. Aggregator,
allegations about responsiveness are being made to them. C means this
level of response.
DaveWatson: for any given facility (commercial, ind, res) only a
handful of things that can be done. Shouldn't overthink this. Varies
from fac to fac. At any one fac, only a small number of strat that can
be done. Can't envision all of them for all customers. As simple as
possible but no simpler.
Michel Why does it have to be on the server? Why does the server have
to know what it means?
Ed: simple/practical -- for existing control systems (legacy issue):
Going forward less used. Existing - allows them to install inexpensive
std eq, listen to the DRAS, use existing levels. No upgrade of
software. Can use existing software. Inexpensive way to fac existing
control systems.
M: Moderate may mean something to one building, something else to
anothers.
B: stored at server.
Ed: Finite set of signal levels.
T: Dualling set point resets - if more than one controller. Our
interface has to be to talk to the EMS.
Ed: Let me qualify - talking to the EMS. One thing you'll find with
existing control systems - diff control networks. Dry relay contact
inputs. This isn't controlling anything, it's a translator of XML from
the DRAS into relay contacts to the EMS.
Mich: Concern that users are defining things on the server where should
be on the EMS. If agree that this is a legacy thing, going forward
address legacy differently, I wouldn't have a problem. Even simple
microcontrollers can store state based on different variables.
Ed: Sign up, tell them to spend $10ks to integrate, barrier to entry.
Mich: Right now have device to talk to DRAS.
Ed: No device now, emerging market. Less used mech down the road. Going
into a deployed system, have a cost issue.
Mich: already a device that listens to DRAS, turns relays on/off. Why
not put logic in that device.
Ed: Have to program that device. But have to program that device
somehow.
B: Web access, stored in the server.
Ed: Yes, but as gen prin should explore more fully. What can end users
do to configure?
B: Scalability issues - stateless.\
Mich: Personalizing what signals should mean to different people. Not
well defined interfaces. If personalize what events mean, talk
separately.
Ed: One thing to point out - can't avoid (putting aside personalizing
signals) - there are programs that require people to bid in on an
event-by-event.
4A954BC7.6070305@CoxSoftwareArchitects.com" type="cite">
Thanks!
bill