Hi All,
I missed the last meeting and I am
wondering if there is a consensus/majority opinion forming around some
questions:
- Are
we thinking that “programs” should be in the CD02 revision?
- Is
there a firming position around how the actors should be described, if at
all?
- Is
there a shared view that the Operator – Building ESM interface is at
a different place in the architecture than the OpenADR DRAS Client –
Server interface? …and where we should focus our next revision?
Personally, I tend to favor focusing at
first on the request/response interaction of the “EventInfo” type
of information (change in price, change in level of requested demand limiting)
and a building’s response to it. (And by focusing on that first I
am not suggesting that other more complicated interactions (DR Bidding, etc) are
not a part of the final specification, just that we start somewhere.)
Best Regards,
Dave
p.s. I apologize for throwing a few
questions in the air. I do it because I would like to see a little more
discussion on the list. Thanks!
From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com]
Sent: Wednesday, August 26, 2009
10:59 AM
To: Energy Interoperation TC
Subject: [energyinterop] Re: Notes
on semantics and models
Raw notes on this discussion at the TC meeting.
Actions not defined yet.
Thanks!
bill
--
William Cox wrote:
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.
(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.
(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.
(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.
(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.
Thanks!
bill