Re: Notes on semantics and models

[William Cox <wtcox@CoxSoftwareArchitects.com>]

Raw notes on this discussion at the TC meeting. Actions not defined yet.

Thanks!

bill
--

William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax

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

--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax