So some of the missing EIQuote stuff, if needed, needs to be submitted into EnergyInterop. Thant makes sense. I sense that we need to look at the quite different messaging and state models to complete the understanding. It appears that the SE model uses what I would call a “control block” method of communications, in which the entire contents of a state engine are passed as a block. There are good reasons to do this, particularly when the subservient system is controlled by and interacts with exactly one outside source. In EI, we have a model of autonomous systems exchanging messages. Those systems may be comparing multiple outside sources of information, and have their own perspectives on past history, and their own predictions about the future. They have a fluidity of potential response. If all communications is exclusively within a hierarchical master-slave communications scenario, and indeed one in which the slave may only discover its own performance by asking the master, control blocks is the only way to go. In such a case, inheritance, memory, autonomy, make no sense at all. It also makes little sense to change the way it is done now if it works. Here, I imagine a transition point. If the external surface of the ESI is in an open market, or event an event-driven market, it can be making its own decisions. Some of the schedule and control decisions might come from direct occupant interactions. Some might come from 3 rd party weather predictions. They almost certainly won’t come entirely from a single message from a sole source. So if we have an ESI, communicating with a variety of information sources, and that has gone through registration, and enrollment, can it, as the sum of the information it has built up over time, generate a control block information to allow the in-building system to work as well as that same system does when controlled as part of the hierarchy. In such a model do we need the links? If they all were “See ESI” would functionality be hurt? Just trying to understand what purpose is served by these elements if the control block is not part of the hierarchical system. Thanks tc " It is the theory that decides what can be observed ." - Albert Einstein Toby Considine Chair, OASIS oBIX Technical Committee U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Facilities Technology Office University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu Phone: (919)962-9073
http://www.oasis-open.org blog:
www.NewDaedalus.com From: Bartell, Bruce [mailto:
bbartell@xtensible.net] Sent: Friday, August 05, 2011 8:46 AM To:
Toby.Considine@gmail.com;
emix@lists.oasis-open.org Subject: RE: [emix] Groups - Mapping eiQuote for block power to SE2 Price message (PriceMsgMapping 20110804.xls) uploaded Some more general comments: The red indicates something that is in SE2 Price that does not have a home in the EiQuote that I can find. It could be I am wrong (it happens). If it is something that is not part of price or product, it may have to be an extension in eiQuote, and not in EMIX. Re: Use of “Resource” in SE2. They are using resource in the Resource Oriented Architecture sense. It is not the DR or EMIX Resource. The links are in as a reference. SE2 is using links in a similar fashion to EMIX or WSCal attachments, except they are explicit to a specific part of the schema. Re: BillingPeriodInterval. See, you do remember the conversation on this last May or June. The thing that I said was not needed was a current meter reading. BillingPeriod.interval is defined as “The time interval for this billing period.” With a datatype of datetimeinterval which is a start datetime and end datetime. Bruce Bartell Xtensible Solutions Mobile: +1.321.258.6500
bbartell@xtensible.net www.xtensible.net
Original Message----- From: Toby Considine [mailto:tobyconsidine@gmail.com] On Behalf Of Toby Considine Sent: Thursday, August 04, 2011 5:52 PM To: Bartell, Bruce; emix@lists.oasis-open.org Subject: RE: [emix] Groups - Mapping eiQuote for block power to SE2 Price message (PriceMsgMapping 20110804.xls) uploaded Thanks, Bruce. Very useful. On some of the red elements: MRID is an acceptable member of EMIX Interface as extended in the Power schema. Name and Description appear to be application specific elements Href, replyTo, responseRequired, signatureRequired, subscribable appear to be part of the facts associated with a resource during registration and enrollment (part of EI). ActiveTimeTariffIntervalListLink - Can you tell me what " Contains the object instances from the list where the current time is within the interval of the object" means? We have an artifact / message creation time, which can be used to compute this if it is what I think it is AccumulationBehaviour - do we need all of these elements in the measurement section of EI? If a subset, which ones do we need. Data Qualifier - do we need all of these elements in the measurement section of EI? If a subset, which ones do we need. ReadingType timeAttribute - see EI tou "TOUType" 0 = NotApplicable 1 = TOU A 2 = TOU B 3 = TOU C 4 = TOU D 5 = TOU E 6 = TOU F 7 = TOU G 8 = TOU H 9 = TOU I 10 = TOU J 11 = TOU K 12 = TOU L 13 = TOU M 14 = TOU N 15 = TOU O" >> what does this mean? BillingPeriod.Interval: I thought you indicated in June that we did not need this. Thanks tc I would note that several of the transactive elements would be in the VEN-VTN services rather than in EMIX itself. "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you." - Fredrich Nietzche Toby Considine TC9, Inc TC Chair: oBIX & WS-Calendar TC Editor: EMIX, EnergyInterop U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee Email: Toby.Considine@gmail.com Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com
Original Message----- From: bbartell@xtensible.net [mailto:bbartell@xtensible.net] Sent: Thursday, August 04, 2011 5:30 PM To: emix@lists.oasis-open.org Subject: [emix] Groups - Mapping eiQuote for block power to SE2 Price message (PriceMsgMapping 20110804.xls) uploaded The document revision named Mapping eiQuote for block power to SE2 Price message (PriceMsgMapping 20110804.xls) has been submitted by Bruce Bartell to the OASIS Energy Market Information Exchange (eMIX) TC document repository. This document is revision #2 of PriceMsgMapping 20110510.xls. Document Description: Mapping document for SE2 Price Message to eiQuote Service. The spreadsheet shows mapped and missing elements for price message. The list was prepared using the eiQuote Message from EI, but the the message content is derived from emixBase. The same document has been uploaded to EI and EMIX. Applicable to EMIX JIRA issues 129 & 304. View Document Details: http://www.oasis-open.org/committees/document.php?document_id=43102 Download Document: http://www.oasis-open.org/committees/download.php/43102/PriceMsgMapping%2020110804.xls Revision: This document is revision #2 of PriceMsgMapping 20110510.xls. The document details page referenced above will show the complete revision history. PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration