energyinterop — archive

State of the schemas - EiClasses

From: Toby Considine <[email protected]>
To: [email protected]
Date: Mon, 06 Jun 2011 00:26:00 -0000

We could use the oBIX historian service, already defined, already on the list of SG standards, already defines set / forget / come back, arguably already compliant with PAP10 <obj is="obix:HistoryQueryOut"> <int name="count" val="9"> <abstime name="start" val="2005-03-17T12:00"/> <abstime name="end" val="2005-03-17T14:00"/> <list name="data" of="#HistoryDef obix:HistoryRecord"> <obj> <abstime name="timestamp" val="2005-03-17T12:00"/> <real name="value" val="80"> </obj> <obj> <abstime name="timestamp" val="2005-03-17T12:15"/> <real name="value" val="82"></obj> <obj> <abstime name="timestamp" val="2005-03-17T12:30"/> <real name="value" val="90"> </obj> <obj> <abstime name="timestamp" val="2005-03-17T12:45"/> <real name="value" val="85"> </obj> <obj> <abstime name="timestamp" val="2005-03-17T13:00"/> <real name="value" val="81"> </obj> <obj> <abstime name="timestamp" val="2005-03-17T13:15"/> <real name="value" val="84"> </obj> <obj> <abstime name="timestamp" val="2005-03-17T13:30"/> <real name="value" val="91"> </obj> <obj> <abstime name="timestamp" val="2005-03-17T13:45"/> <real name="value" val="83"> </obj> <obj> <abstime name="timestamp" val="2005-03-17T14:00"/> <real name="value" val="78"> </obj> </list> <obj href= "#HistoryRecord" is="obix:HistoryRecord"> <real name="value" units="obix:units/kilowatt"/> <obj> </obj> Obix also support requesting feedback on other historical points:: < <obj is="obix:HistoryRollupOut obix:HistoryQueryOut"> <int name="count" val="2"> <abstime name="start" val="2005-03-16T12:00"/> <abstime name="end" val="2005-03-16T14:00"/> <list name="data" of="obix:HistoryRollupRecord"> <obj> <abstime name="start" val="2005-03-16T12:00"/> <abstime name="end" val="2005-03-16T13:00"/> <int name="count" val="4" /> <real name="min" val="81" /> <real name="max" val="90" /> <real name="avg" val="84.5" /> <real name="sum" val="338" /> </obj> <obj> <abstime name="start" val="2005-03-16T13:00"/> <abstime name="end" val="2005-03-16T14:00"/> <int name="count" val="4" /> <real name="min" val="78" /> <real name="max" val="91" /> <real name="avg" val="84" /> <real name="sum" val="336" /> </obj> </list> </obj> Using more oBIX syntax, we could request alarm states for feedback as well. http://www.oasis-open.org/committees/download.php/21462/obix-1.0-cs-01.zip 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: Koch, Edward [mailto:[email protected]] Sent: Sunday, June 05, 2011 7:36 PM To: [email protected] Subject: RE: [energyinterop] State of the schemas - EiClasses Comment with respect to the following: Most significant: Now derived from EventBase, meaning it can apply to a schedule. Does this mean that we could collect feedback at 15 minute intervals (schedule) and send at the end of the day? Do we need a message for whter Feedback should be accumulated or shared live? Yes we do. The "measurement interval" addresses how often it should be measured; the "reporting interval" addresses how often or how many feedback items are packaged. Ø We should not tightly couple the reporting interval with how many data points are packaged with each message. It may be that we measure at 5 minute intervals, report at 15 minute intervals and “package” data for each report that covers the last 2 hours. That means that for each message at the 15 minute reporting interval there may be data that is redundant with the previous message, but this is a common method of dealing with “missed” reports and insures higher reliability of the data stream. Thanks, -ed Koch From: William Cox [mailto:[email protected]] Sent: Saturday, June 04, 2011 11:20 AM To: [email protected] Cc: [email protected] Subject: Re: [energyinterop] State of the schemas - EiClasses Notes interleaved. Good overview of issues. Thanks! bill -- William Cox Email: [email protected] Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 6/2/11 9:40 AM, Toby Considine wrote: Summary of changes to EI-Classes Schema in Ed Koch’s sumission EiMarketContext now has an optional emix:MarketContext. Observation: eiMarketContext now identified with a uid. emicMarketContext is solely a uri-style uid. If eiMakretContext has both, possibility of some sort of collision/incompatibility. As EI often is a transport for “emixes”, removes the possible conformance issue of matching the EiMarketContext with that in EMIX. Also removes alternate rule that all packages inherit from the larger context. Seems right to me. eiFeedback Changed from < xs:complexType name =" EiFeedback "> < xs:sequence > < xs:element ref =" eitc:eventID " minOccurs =" 0 " maxOccurs =" 1 "/> < xs:element name =" feedbackInfo " type =" xs:anyType " minOccurs =" 1 " maxOccurs =" 1 "/> < xs:element ref =" eitc:resourceID " minOccurs =" 0 " maxOccurs =" unbounded "/> < xs:element ref =" ts:timeStamp " minOccurs =" 1 " maxOccurs =" 1 "> < xs:annotation > < xs:documentation > Feedback TimeStamp </ xs:documentation > </ xs:annotation > </ xs:element > < xs:element ref =" eitc:transactionName " minOccurs =" 0 " maxOccurs =" 1 "/> < xs:element ref =" eitc:venID " minOccurs =" 0 " maxOccurs =" 1 "/> </ xs:sequence > < xs:attribute ref =" eitc:schemaVersion " use =" optional "/> </ xs:complexType > To (Ed's EiFeedback schemas) Per our discussion on Resource IDs this should be aligned with ResourceTarget (cardinality 0..* here). Other comments from our June 1 meeting notes. Definitely the right direction. Bundling and schedule for feedback - first comment below; I'll follow up there. < xs:complexType name =" EiFeedback "> < xs:complexContent > < xs:extension base =" eitc:EventBaseType "> < xs:sequence > < xs:element ref =" eitc:eventID " minOccurs =" 0 " maxOccurs =" 1 "/> < xs:element ref =" eitc:resourceID " minOccurs =" 0 " maxOccurs =" unbounded "> < xs:annotation > < xs:documentation > ??? </ xs:documentation > </ xs:annotation > </ xs:element > < xs:element ref =" eitc:transactionName " minOccurs =" 0 " maxOccurs =" 1 "> < xs:annotation > < xs:documentation > ??? </ xs:documentation > </ xs:annotation > </ xs:element > < xs:element ref =" eitc:venID " minOccurs =" 1 " maxOccurs =" 1 "/> < xs:element name =" dataSourceID " type =" xs:string "> < xs:annotation > < xs:documentation > This is the source of the data within the VEN, i.e. "meter1". </ xs:documentation > </ xs:annotation > </ xs:element > < xs:element name =" dataSetID " type =" xs:string "> < xs:annotation > < xs:documentation > This is the identifier for the data set within the dataSource, i.e. "phase1" </ xs:documentation > </ xs:annotation > </ xs:element > </ xs:sequence > < xs:attribute ref =" eitc:schemaVersion " use =" optional "/> </ xs:extension > </ xs:complexContent > </ xs:complexType > Discussion: Most significant: Now derived from EventBase, meaning it can apply to a schedule. Does this mean that we could collect feedback at 15 minute intervals (schedule) and send at the end of the day? Do we need a message for whter Feedback should be accumulated or shared live? Yes we do. The "measurement interval" addresses how often it should be measured; the "reporting interval" addresses how often or how many feedback items are packaged. Schema now calls out undefined items by giving them an annotation “???”. This makes the object appear much larger, but it is not. ResourceId. Is it the Asset sneaking back in? Is it an MRID? Is it a virtual construct for an aggregator? Lots of discussion Wednesday, few conclusions, general sense that whateveriti is, it needs to match something similar in enrollment. Noteworthy that schema as pointedly unable (“???”) to define. We identify ResourceTarget in the EiEvent; the Resource is in the context of the VEN, and the information it delivers to the VTN. See comments below on ID/mRID. An aggregator must create a resource to bid into a market; that reflects its aggregation. The VTN presentation of an aggregator will know about the resources the aggregator can call on, and the aggregator does its magic to figure out what it can safely and economically bid. TransactionName – no definition. Timestamp eliminated Which timestamp? If we deliver a Schedule then we're fine - the applicable Interval identifies what the timestamp was used for. Now includes a datasource (perhaps a meter) and a datasetId (sub meter Identifier, e.g.) I think this is an Interface from EMIX, as there are many ways of measuring, not just a meter. Not sure where the data is, though. EventDescriptor. eiMarketContext now optional (minOccurs=0). See discussion under eiMarketContext. EiEventSignalType. More precise cardinality, including emix:marketContext as above. Added “CurrentValue as a schedule free addition to be alongside schedule w/ all optionality of messages w/I each schedule. As long as it's a cached value, valid when sent, that's fine; but the value(s) in the EiEvent family control. I have no issue with caching (and using the appropriate type to identify whether it's a multiplier, adder, simple level, etc) General Issues in Schema: There are a number of elements that are defined “in-line”. We may wish to promote them and use them by ref in the types… eiBusinessSchedule can be replaced through direct reference to xcal:vavailability Intervals. The EiInterval still looks like a conforming ws-calendar interval. The reduction in optionality is useful. Open issue whther ot stick with eiIntervals or incorporate by reference. May need to produce some examples to finalize decision. Even ws-calendar may benefit from demonstration of conforming spec that has been deliberately tightened up. One issue: dtstart does not include time zone id as it is conformed away from ws-calendar. Do we go pure UTC? Inherit a single tzid context for an entire event? I think that mixing timezones in a single event is highly risky at best - I recommend putting it in the EiEvent and not putting it in the Intervals. A more general inheritance rules might be useful here, but I see only negatives to including (repeating) the timezone with each dtStart. Speaking of flabby XML... Enumerated strings: I *think* our standard is lowerCamel TOKEN for these. Some are UpperCamel. I think that's right. PartyIdType hints that it has some rules and restrictions, but as of yet does not. I'd delete the hints...part of the more general ID (see below) PartyIdType is referenced in multiple elements We need a single type to inherit from - see below eventModificationNumber – what type is it unsigned 0, 1, 2, ... - it's really a "generation number" sort of thing. eventStateId – any rules? An enumeration? Not sure on this one. marketName is a string. How is this different frm emox:marketCOntext? marketContext is a global element; marketName is a human-readable string that gives the name of the market, e.g. PGE_Program_32 or NYMEX Any ID rules or typing?? I think the structure should be Uid is a subclass of string All "ID"s are subclasses (do we need a substitution group?) of Uid (or UidType) Uid constraintId eventId offerID optID quoteID resourceID programCallID registrationID responseSchedID tenderID transactionID venID vtnID partyId All "Names" are human readable strings, and inherit from string (or probably better) a NameType that is a null extension of string. Generic strings? agreementName partyName partyRole signalName transactionName “The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw. 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: [email protected] Phone: (919)619-2104 http://www.tcnine.com/ blog: www.NewDaedalus.com