working document for help desk items. - home - open …osgug.ucaiug.org/sgsystems/openade/shared...

Summary of Help Desk as of 11/29/2015http://osgug.ucaiug.org/HelpDesk/Lists/servicerequests/GreenButton.aspx

[ 56] ESPI standard doesn't allow negative values [Tom Kring]............................................................3

[ 57] Use of UUIDs for UsagePoint should be persistant across lifetime of association........................3

[ 58] Guidelines are needed for proper usage of hrefs in the Atom representation.............................4

[ 60] Green Button file names contains PII...........................................................................................7

[61] ESPI lacks clarity for sending OAuth authorizations in batch............................................................7

[ 62] Timestamps are Universal so where is timezone and DST info.....................................................8

[ 64] ESPI ElectricPowerUsageSummary needs usage total to go with last period.............................12

[65] How many Interval blocks should there be per entry....................................................................12

[66] Meaning of UsageSummary may need (direction) clarification......................................................12

[ 67] Extend costAdditionalLastPeriod with optional details..............................................................12

[ 68] Add ESPI Use Case for Green Button data file download [Anne Hendry]...................................13

[ 69] CurrencyCode is UINT8 but needs to be UINT16........................................................................14

[ 70] Incorporate 61968-9 enumerations into schema.......................................................................14

[ 71] Add tariff profile and service delivery point as optional addition to usage point.......................15

[ 72] Remark about test # FDFTP6 (related links matching self links).................................................15

[ 73] Green Button test for stability of UUIDs needed........................................................................15

[74] Add additional UsageSummary structures for Gas and Water.......................................................16

[ 75] Logical Information Model components should be part of model.............................................16

[76] CSWG REQ 21 review - NISTIR 7628 References............................................................................16

[77] CSWG REQ 21 review - RFC 5849 OAuth 1.0..................................................................................17

[78] CSWG REQ 21 review – TLS............................................................................................................17

[79] CSWG REQ 21 review – References................................................................................................17

[ 80] DateTimeInterval should make attributes optional....................................................................17

[ 81] Modify UsagePoint/RoleFlags to match SEP2.............................................................................18

[ 82] How to communicate ‘greenness’ of Energy During an Interval (Scott.Crowder).......................18

[ 83] Add a PII element that is optional (jim.vezina, NREL).................................................................19

[84] Scope Selection page on Data Custodian site vs 3rd Party Site......................................................20

[85] Time of Use tier indicator alignment with SEP 2.0.........................................................................20

http://osgug.ucaiug.org/HelpDesk/Lists/servicerequests/GreenButton.aspx

[86] Proposal for Green Button Security/Privacy Enhancement............................................................21

[88] Change title of ElectricPowerUsageSummary to UsageSummary and extend...............................21

[89] ESPI Schema extension: Revenue Quality value for Quality of Reading Flag.............................23

[90] Error in GB TestPlan: FB_07,08 AccumulcationBehavior should be 4.............................................23

[91] Error in Test Plan: FB_04................................................................................................................23

[92] Need to include <link> reference to Certification ID......................................................................24

[93] Customers have requested access to the Green Button CMD API interface to access their own account information..............................................................................................................................24

[94] Inclusion of Read Cycle to Usage Point and Usage Summary.........................................................24

[95] Green Button Download My Data Gas Function Block [FB_10] only allows "therms" UOMType = 169.........................................................................................................................................................25

[96] Green Button Download My Data Gas Function Block [FB_11] only allows UOMType = 128 (US gl (US Gallons)...........................................................................................................................................25

[97] Update UsagePoint for 61968-9 2nd edition elements..................................................................25

[xx] title.................................................................................................................................................26

[ 56] ESPI standard doesn't allow negative values [Tom Kring]

We have run into a problem with our Green Button implementation that has led to a concern about one aspect of the ESPI standard. The <value> element, child of the <IntervalReading> element, is defined as Uint48 – an unsigned integer value.

With our current implementation, this will be a problem for net meters, since we are only outputting the net data, which could contain negative values. We could fix our implementation to output the delivered and received data separately - as long that’s what we receive from the meter. There are still meters out there that only record the net usage. Also, we’re wondering if there may be other use cases where the values may be either positive or negative – temperature data, for example.

The CIM Part 9 equivalent of this element defines the value as a string.

Comments:

steve.van ausdall (2/2/2012 4:27 PM): Should also change SummaryMeasurement.value to Int48.

steve.van ausdall (1/3/2012 5:57 PM): Suggest defining and changing type to Int48, derived from xs:long, Signed integer, max inclusive 140737488355328 (2^47), min inclusive -140737488355328

Marty: same argument applies to cost values …

Recommendation of OpenADE Task ForceChange data type of SummaryMeasurement.value, IntervalReading.value, IntervalReading.cost to Int48. [NAESB]

[ 57] Use of UUIDs for UsagePoint should be persistant across lifetime of association

UUIDs for UsagePoints should be recommended to be persistent so that they can be associated with actual UsagePoints in the field and updates can be recognized.

06/12: Anne: Usage point versus meter, etc.

No changes.

Comments:

Recommendation of OpenADE Task ForceMake UUID for UsagePoint retention required in Green Button test plans. The UUIDs should be constant over the lifetime of the association between the Retail Customer, the Data Custodian, and the Third Party. The UUIDs should be unique for each three-way association (or two-way association for DMD) and not reused. [NAESB]

[ 58] Guidelines are needed for proper usage of hrefs in the Atom representation

At the Grid-Interop 2011, we discussed the use of atom:link elements with rel="up" in the Green Button file format. These links are meant to point from an atom:entry (e.g., /UsagePoint/1/MeterReading/1) to its hierarchically superordinate atom:entry (e.g., /UsagePoint/1), and we came to the conclusion that they should use, e.g., href="/UsagePoint/1", whereas in the examples given in the NAESB draft they use href="/UsagePoint/1/MeterReading", i.e., they point to a collection, not to an entry.

On my flight home, I have thought about this question again, and I now consider our conclusion premature.

Although up-links that point to an entry make it easier to select the hierarchically superordinate atom:entry, they prevent the other direction, making it impossible to select the hierarchically subordinate entries. For example, an <atom:link rel="up" href="/UsagePoint/1"/> would not only be found in the atom:entries for the MeterReadings, but also in the atom:entries for the ElectricPowerUsageSummaries, and these two kinds of subordinate entries cannot be distinguished without decomposing the URLs in the hrefs, what we wanted to avoid in the first place.

On the other hand, up-links that point to collections make it possible to elegantly select (with the help of XPath expressions) both the superordinate and the subordinate elements. Given an atom:entry element, we can select• the hierarchically superordinate element by putting the context on the given atom:entry's up-link and evaluating the XPath expression../../atom:entry[atom:link[@rel="related"]/@href=current()/@href](we select the entry whose related-link points to the same collection as the current up-link)• the hierarchically subordinate elements of a given type (e.g., the MeterReadings, but not the ElectricPowerUsageSummaries) by putting the context on the corresponding related-link and evaluating the XPath expression../../atom:entry[atom:link[@rel="up"]/@href=current()/@href](we select the entries whose up-links point to the same collection as the current related-link).These selections work for 1:n relationships between super- and subordinate elements, where both the related-link and the up-link have type="application/atom+xml;type=feed".

But there are also 1:1 relationships• either hierarchically from a super- to a subordinate element (e.g., the ElectricPowerQualitySummary subordinate to a UsagePoint) where both links have type="application/atom+xml;type=entry"• or associations independent of the hierarchy (e.g., the ReadingType related to a UsagePoint), here the related-link has type="application/atom+xml;type=entry" (but the up-link of the ReadingType points to the feed of ReadingTypes and has type="application/atom+xml;type=feed").In the case of such 1:1 relationships, analogous XPath expressions to the ones shown above can be used, where [@rel="up"] is replaced by [@rel="self"] (and the parenthesised "we select" remarks should read "the same entry" instead of "the same collection").

To summarise: I now believe that the up-links given in the NAESB draft are perfectly valid.

Comments:

heiko.theißen (4/12/2012 11:03 AM): The way I would expect the atom:links to be interpreted can be expressed in the following XSLT templates:

<xsl:template match="atom:link[@rel='related']"><xsl:variable name="target" select="ancestor::atom:feed/atom:entry/atom:link[@rel!='related' and @href=current()/@href]"/><xsl:choose><xsl:when test="$target/@rel='self' and$target/../atom:link[@rel='up']/@href=../atom:link[@rel='self']/@href"><xsl:apply-templates select="$target/.." mode="hierarchical-relation-1-1"/></xsl:when><xsl:when test="$target/@rel='self'"><xsl:apply-templates select="$target/.." mode="non-hierarchical-relation-1-1"/></xsl:when><xsl:when test="$target"><xsl:apply-templates select="$target/.." mode="relation-1-n"/></xsl:when></xsl:choose></xsl:template>

<xsl:template match="atom:link[@rel='up']"><xsl:variable name="target" select="ancestor::atom:feed/atom:entry/atom:link[@rel!='up' and @href=current()/@href]"/><xsl:choose><xsl:when test="$target/@rel='self'"><xsl:apply-templates select="$target/.." mode="hierarchical-relation-1-1"/></xsl:when><xsl:when test="$target"><xsl:apply-templates select="$target/.." mode="relation-1-n"/></xsl:when>

</xsl:choose></xsl:template>

heiko.theißen (4/12/2012 10:54 AM): I think that the usage of these links is not yet uniformly observed in all the Green Button examples that are "out there". The sample data by SDG&E http://www.greenbuttondata.org/greendevelop.html are correctly linked, they seem to have been copied from the original sample https://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/GreenButtonInitiative/GETBatchSampleEUI.xml with only the IntervalBlock contents replaced.

I found one other set of sample data by PGE http://pge.com/includes/docs/xml/shared/greenbutton/XML

%20Sample%20Residential%20Electric%20Usage%2007072011%2012032011.zip, and here the atom:links are not used in the way I expect:• The UsagePoint entry contains a related-link to a MeterReading entry whereas it should link to a MeterReading feed.• The MeterReading entry should contain an up-link to the MeterReading feed /UsagePoint/xxx/MeterReading, but it does not.• The MeterReading entry contains a related-link to an IntervalBlock entry whereas it should link to an IntervalBlock feed.• The IntervalBlock entry should contain an up-link to the IntervalBlock feed /UsagePoint/xxx/MeterReading/yyy/IntervalBlock, but it does not. (There are no up-links at all in the sample.)

The hierarchial relationship between the entries in PGE's sample can only be derived from the internal structure of the hrefs, by splitting these URIs at the slashes. But in my opinion this should not be done, since these URIs are assumed to be opaque.

The usage of atom:links is probably irrelevant to "Green Button apps" that only visualize the IntervalReadings for one UsagePoint. But the issue should become relevant as more complex apps are developed. A common understanding about the links between producers of Green Button data (energy companies) and consumers (app developers) is perhaps not yet reached.

martin.burns (1/31/2012 2:25 PM):

Recommendation of OpenADE Task ForceFor discussion white paper see : http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/referenceMaterial/GreenButtonAtomLinks.docx

Best Practices: [NAESB]

1. Every entry shall have an uplink to its parent feeds.

2. URLs are opaque and not designed to be parsed for navigation. They may reflect the internal storage or layout of the servers which will vary. Therefore clients should not make any assumptions about their structure.

3. If a server supports retrieving feeds, the feeds shall have an uplink to its parent entry.

4. When the multiplicity in the data model is not 1:1, the “related” link must point to a feed

5. When the multiplicity in the data model is 1:1, the “related” link must point to an entry

6. Batch defines the set of atom entrys that pertain to a common single Authorized resource.

7. Bulk defines a set of atom entrys that pertain to multiple authorized resources theoretically with separate individual or Batch authorizations.

8. A Subscription pertains to any single resource. However, Subscription is probably always a feed.

http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/referenceMaterial/GreenButtonAtomLinks.docx

http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/referenceMaterial/GreenButtonAtomLinks.docx

9. Use of BatchItemInfo. If you want to support multiple requests (e.g. http requests) in a single call, you would need BatchItemInfo to distinguish the results. This probably needs to be elaborated further in the standard. *** should result in a new Help desk item

10. All collections of atom entrys are returned as a feed.

11. entry/@base or feed/@base may have a common URL base after which all relative link URIs are appended. e.g. feed/@base = http://my.web.com/DataCustodian/. If there is a conflict between base and a resource link, use the resource link.

[ 60] Green Button file names contains PII

Are the early implementations of Green Button encoding PII in the exported filenames? One of the primary tenets of ESPI is the "separation of privacy" between Data Custodian and 3rd Party; encoding PII in the filename allows that information to leak between the Custodian and 3rd Party.

Comments:

Recommendation of OpenADE Task ForceAdd inspection test for Green Button Data in the test plans.

[61] ESPI lacks clarity for sending OAuth authorizations in batch

If it is possible to send updates for resources requiring multiple distinct authorizations, the method for doing so needs to be defined. One possible way would be to add signature_method, signature, and nonce to Authorization and allow it to be included with BatchItemInfo. Otherwise, if Data Custodians are to verify valid authorization within batch POSTs, and reject submissions associated with resources to which the Authorized Thrid Party does not have authorization, that should be specified.

06/12: Can we clarification from Steve Van Ausdall on this? Is he proposing that there be facilities for multiple tokens in a batch response?

Comments:

donald.coffin (8/17/2012 4:52 PM): Assuming the definition of "bulk" and "batch" as described in John Teeter's definition. The current OAuth flow should be capable of handling the "batch" situation, since it requires the Data Custodian to only verify the authorization of a single user. The "bulk" situation requires the Data Custodian to verify the user has authorization to access the data of multiple Retail Customers. One method of achieving this would be for the Data Custodian to establish a "unique" UserID for the "bulk" user account which would then allow the "bulk" transfer transaction to utilize the same OAuth process as all other users. For the "bulk" user to gain access to various different Retail Customer's data, the Data Custodian would then be required to establish a technique that a Retail Customer can use to "grant" permission to the "bulk" user to access their data. The definition of this "granting" process is beyond the scope of the ESPI standard and therefore is NOT covered.john.teeter1 (8/14/2012 3:31 PM): We had a brief discussion about "Batch" on OpenESPI call. While we didn't resolve the OAuth question directly, we figure there were two categories of things: "Batch" and "Bulk" where: Batch is the delivery of multiple resources under the auspices of a single Retail Customer's

http://my.web.com/DataCustodian/

authorization. Bulk is the delivery of multiple resources under the auspices of 1 or more Retail Customer's authorization. I could do a "batch" request for multiple subscriptions owned by one user; or I might do a "bulk" request for multiple subscriptions each of which might be owned by different Retail Customers. The OAuth implications of the two (batch.vs.bulk) seem to be unique.

Recommendation of OpenADE Task Force

[ 62] Timestamps are Universal so where is timezone and DST info

Reading the standard, the key reference I see to timestamps is RFC3339 “Date and Time on the Internet: Timestamps”. This standard clearly states that UTC is the default and preferred representation. In the ESPI standard, this is referred only in the communication specifications section 21.6.2: “Date and time values for the above parameters use RFC 3339 format.” For the standard, timestamps in general are based on TimeType which does not make reference to locale. So I would say that the standard is not explicit but implies that all times are UTC.

Comments:

martin.burns (5/21/2012 11:27 AM): Here is a proposed solution -- Based on similar SEP 2 time info data structure. Add a new entry that points up to UsagePoint to contain the LocalTimeParameters for the location of the UsagePoint. Ron Pasquarelli and I have prototyped this approach and works well. All timestamps in the Green Button data file are in UTC reference. The timezone in the LocalTimeParameters can be used in the presentation of the data in local format relative to the source of the data (the UsagePoint).

Here is what the entry would look like in an ESPI data file: <entry> <id>urn:uuid:8A0DE392-EB47-4C01-BED0-5675BF574AFD</id> <link rel="self" href="/User/9b6c7064/UsagePoint/01/LocalTimeParameters"/> <link rel="up" href="/User/9b6c7064/UsagePoint/01"/> <title>DST For North America</title> <content> <LocalTimeParameters xmlns="http://naesb.org/espi"> <dstEndRule>B40E2000</dstEndRule> <dstOffset>3600</dstOffset> <dstStartRule>360E2000</dstStartRule> <tzOffset>-18000</tzOffset> </LocalTimeParameters> </content> <published>1899-12-30T00:00:00Z</published> <updated>1899-12-30T00:00:00Z</updated> </entry>

Here is what the schema part looks like:<xs:complexType name="TimeConfiguration"><xs:annotation><xs:documentation>Contains attributes related to the configuration of the time

service.</xs:documentation></xs:annotation><xs:complexContent><xs:extension base="IdentifiedObject"><xs:sequence><xs:element name="dstEndRule" type="DstRuleType" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Rule to calculate end of daylight savings time in the current

year. Result of dstEndRule must be greater than result of dstStartRule.</xs:documentation></xs:annotation>

</xs:element><xs:element name="dstOffset" type="TimeType" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Daylight savings time offset from local standard

time.</xs:documentation></xs:annotation>

</xs:element><xs:element name="dstStartRule" type="DstRuleType" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Rule to calculate start of daylight savings time in the current


</xs:element><xs:element name="tzOffset" type="TimeType" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Local time zone offset from UTCTime. Does not include any

daylight savings time offsets.</xs:documentation></xs:annotation>

</xs:element></xs:sequence>

</xs:extension></xs:complexContent>

</xs:complexType>

<xs:simpleType name="DstRuleType"><xs:annotation><xs:documentation>Bit map encoded rule from which is calculated the start or end time, within

the current year, to which daylight savings time offset must be applied.

The rule encoding:Bits 0 - 11: seconds 0 - 3599Bits 12 - 16: hours 0 - 23Bits 17 - 19: day of the week 0 = not applicable, 1 - 7 (Monday = 1)Bits:20 - 24: day of the month 0 = not applicable, 1 - 31Bits: 25 - 27: operator (detailed below)Bits: 28 - 31: month 1 - 12

Rule value of 0xFFFFFFFF means rule processing/DST correction is disabled.

The operators:

0: DST starts/ends on the Day of the Month1: DST starts/ends on the Day of the Week that is on or after the Day of the Month2: DST starts/ends on the first occurrence of the Day of the Week in a month3: DST starts/ends on the second occurrence of the Day of the Week in a month4: DST starts/ends on the third occurrence of the Day of the Week in a month5: DST starts/ends on the forth occurrence of the Day of the Week in a month6: DST starts/ends on the fifth occurrence of the Day of the Week in a month7: DST starts/ends on the last occurrence of the Day of the Week in a month

An example: DST starts on third Friday in March at 1:45 AM. The rule...Seconds: 2700Hours: 1Day of Week: 5Day of Month: 0Operator: 4Month: 3

</xs:documentation></xs:annotation>

<xs:restriction base="HexBinary32"/></xs:simpleType>

martin.burns (4/6/2012 8:07 AM): An ESPI data file as used for Green Button, for example, currently has no time zone information. The third party will not necessarily know the time zone that the data is for (the UsagePoint). Therefore, he can't render it to the Retail Customer in the appropriate time zone.

Therefore it seems reasonable that the data must have only UTC and that time zone and DST information needs to be added to the UsagePoint definition.

I suppose alternatively, a hint at the time zone information could be deduced from the atom publishing part of the data but this seems unsatisfying as it is header information that might not be retained in a user's application.

steve.van ausdall (3/19/2012 4:48 PM): RFC 3339 is only used "for the above parameters" which are published and updated max and min (query parameters). Atom (RFC 4287) defines published and updated using xsd:dateTime, which is similar to ISO 8601 (allows specification of time zone), and ESPI uses "TimeType" which is similar to unix time (UTC / no time zone). If the field in question allows specification of a time zone, then times can be specified in relation to a specific time zone, but it is not required. The service provider (DataCustodian) does not need to know the time zone of the service consumer (AuthorizedThirdParty). The third party may need to convert times specified without time zone to local time for display purposes.

John Teeter: iCal (sec 2.2.1) / WS Calendar (sec 2.2.1) has different approach; ought to consider that as well.

Comments:

Recommendation of OpenADE Task Force[NAESB] Recommend to NAESB to extend ESPI to support new resource “LocalTimeParameters”. Add explicit language to standard indicating that all timestamps are to be interpreted as Universal Time Coordinated (UTC).

In Green Button Data this would look like:

<entry> <id>urn:uuid:8A0DE392-EB47-4C01-BED0-5675BF574AFD</id> <link rel="self" href="/User/9b6c7064/UsagePoint/01/LocalTimeParameters"/> <link rel="up" href="/User/9b6c7064/UsagePoint/01"/> <title>DST For North America</title> <content> <LocalTimeParameters xmlns="http://naesb.org/espi"> <dstEndRule>B40E2000</dstEndRule> <dstOffset>3600</dstOffset> <dstStartRule>360E2000</dstStartRule> <tzOffset>-18000</tzOffset> </LocalTimeParameters> </content> <published>1899-12-30T00:00:00Z</published> <updated>1899-12-30T00:00:00Z</updated> </entry>

Here is what the schema part should be:

<xs:complexType name="TimeConfiguration"><xs:annotation><xs:documentation>Contains attributes related to the configuration of the time

service.</xs:documentation></xs:annotation><xs:complexContent><xs:extension base="IdentifiedObject">

<xs:sequence><xs:element name="dstEndRule" type="DstRuleType" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Rule to calculate end of daylight savings time in the current


</xs:element><xs:element name="dstOffset" type="TimeType" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Daylight savings time offset from local standard

time.</xs:documentation></xs:annotation>

</xs:element><xs:element name="dstStartRule" type="DstRuleType" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Rule to calculate start of daylight savings time in the current


</xs:element><xs:element name="tzOffset" type="TimeType" minOccurs="1" maxOccurs="1"><xs:annotation><xs:documentation>Local time zone offset from UTCTime. Does not include any

daylight savings time offsets.</xs:documentation></xs:annotation>

</xs:element></xs:sequence>

</xs:extension></xs:complexContent>

</xs:complexType>

<xs:simpleType name="DstRuleType"><xs:annotation><xs:documentation>Bit map encoded rule from which is calculated the start or end time, within

the current year, to which daylight savings time offset must be applied.

The rule encoding:Bits 0 - 11: seconds 0 - 3599Bits 12 - 16: hours 0 - 23Bits 17 - 19: day of the week 0 = not applicable, 1 - 7 (Monday = 1)Bits:20 - 24: day of the month 0 = not applicable, 1 - 31Bits: 25 - 27: operator (detailed below)Bits: 28 - 31: month 1 - 12

Rule value of 0xFFFFFFFF means rule processing/DST correction is disabled.

The operators:

0: DST starts/ends on the Day of the Month1: DST starts/ends on the Day of the Week that is on or after the Day of the Month2: DST starts/ends on the first occurrence of the Day of the Week in a month3: DST starts/ends on the second occurrence of the Day of the Week in a month4: DST starts/ends on the third occurrence of the Day of the Week in a month5: DST starts/ends on the forth occurrence of the Day of the Week in a month6: DST starts/ends on the fifth occurrence of the Day of the Week in a month7: DST starts/ends on the last occurrence of the Day of the Week in a month

An example: DST starts on third Friday in March at 1:45 AM. The rule...Seconds: 2700Hours: 1Day of Week: 5Day of Month: 0Operator: 4Month: 3

</xs:documentation></xs:annotation>

<xs:restriction base="HexBinary32"/></xs:simpleType>

[ 64] ESPI ElectricPowerUsageSummary needs usage total to go with last period

In the ElectricPowerUsageSummary there is a summary of last billing period's costs but no usage. Suggest adding overallConsumptionLastPeriod measurement.

Comments:

Recommendation of OpenADE Task ForceRecommend that NAESB update ESPI to include overallConsumptionLastPeriod element for ElectricPowerUsage Summary. [NAESB]

[65] How many Interval blocks should there be per entry

According to the schema, a single entry with IntervalBlock can contain one or more instances of IntervalBlock.

According to REST, you can update an entry. Thus if there is a lot of data in an entry you can only update it in total.

Perhaps there should be a guideline for what an IntervalBlock and an interval is.

Finally, should there be one IntervalBlock per entry or an arbitrary number as desired.

Comments:


[66] Meaning of UsageSummary may need (direction) clarification

During 4/10 review of test cases, suggestion was made to discuss and clarify if needed how to specify the direction of commodity in ElectricPowerUsageSummary.

Comments:


[ 67] Extend costAdditionalLastPeriod with optional details

Currently, the costAdditionalLastPeriod in the ElectricPowerUsageSummary is a single value of type float. This attribute is designed to allow all costs allocated in the IntervalReading classes to roll up to the total provided in the UsageSummary.billLastPeriod less the costAdditionalLastPeriod.

Representing cost results this way removes the need for any pricing information and model to be necessary to understand the EUI data which only renders a summary of the results of the application of a pricing model.

It is suggested that this component of the UsageSummary class be extended so that additional optional line items supporting this attribute can be provided.

This change is also being proposed in the update to REQ18/WEQ19 PAP10.

Suggest extending the attribute currently:costAdditionalLastPeriod: Float [0..1]

to add additionally optional set of LineDetail (Model from CIM)

costAdditionalDetailLastPeriod: LineDetail [0..*]

Comments:

Recommendation of OpenADE Task ForceRecommend that NAESB update ESPI to include in ElectricPowerUsageSummary: [NAESB]

costAdditionalDetailLastPeriod: LineDetail [0..*]

[ 68] Add ESPI Use Case for Green Button data file download [Anne Hendry]

The existing ESPI Standard describes 12 Use Case scenarios in the lifecycle of establishing, conducting, and terminating operational relationships between Data Custodian, Customer, and 3rd Party Services Provider for the authorization and exchange of energy usage information. We need a Use Case for the simpler scenario where a Retail Customer requests their own energy usage data from a Data Custodian.

Comments:

Recommendation of OpenADE Task ForceRecommend to add this Use Case to the ESPI standard. [NAESB]

Retail Customer requests Energy Usage Information from a Data Custodian

Use Case Description:

Retail Customer directly requests Energy Usage Information to which they have access rights from a Data Custodian. Upon receiving a valid request, the Data Custodian replies with the requested EUI data.

Invariant Conditions:

1. Request is valid.2. Retail Customer has an existing relationship with the Data Custodian.

Pre-Conditions:

1. Retail Customer has knowledge of how/where to initiate request for EUI.2. Data Custodian is able to confirm identity of requesting Retail Customer.3. Retail Customer is authorized to receive the requested EUI from the Data Custodian.

Post Conditions:

1. Data Custodian has provided EUI to requesting Retail Customer.2. Retail Customer has received the requested Energy Usage Information.

Basic Path Scenario:

1. Retail Customer wishes access to Energy Usage Information.2. Retail Customer validates their identity with the Data Custodian.3. The Data Custodian validates the access rights to the data.4. Data Custodian presents the Retail Customer with a list of available EUI resources and options. 5. Retail Customer requests an EUI resource directly from the Data Custodian.6. Data Custodian responds with the requested Energy Usage Information.

Use Case Scenario component descriptions from Req 22:

· Use Case Description: This is a summary of the use case, describing the overall purpose.· Invariant Conditions: These are properties that will be true any time the use case is initiated, regardless of whether it terminates successfully.· Pre-Conditions: These are conditions that must be true for the use case to be successfully executed.· Post-Conditions: These are properties that will be true only if the use case terminates successfully. This requires that all preconditions and all condition checks (e.g., for validity of a request) be satisfied during execution of the use case.

Basic Path Scenario: This defines the series of steps undertaken by each role during successful execution of the use case. The scenario is depicted graphically in a Unified Modeling Language (UML) sequence diagram and each step is summarized in text.

[ 69] CurrencyCode is UINT8 but needs to be UINT16

In the NAESB REQ21 standard, CurrencyCode is UINT8. This does not hold the standard value for US Dollars which is 840. Need to change:

<xs:extension base="UInt8"/>

to

<xs:extension base="UInt16"/>

Comments:

Recommendation of OpenADE Task ForceRecommend that NAESB modify ESPI to change CurrencyCode from UINT8 to UINT16. [NAESB]

[ 70] Incorporate 61968-9 enumerations into schema

In order to represent the diversity of measurments and descriptors in Green Button Data, more than the initial set of enumerated values identified in the standard should be included. The IEC standard Annex "C" defines a complete list for the attributes in ESPI ReadingType and ServiceKind. These should be added to the standard or implementation agreement.

Comments:

Recommendation of OpenADE Task ForceRecommend that the enumerations that are part of the NAESB PAP10 maintenance update be incorporated into the schema used for the Green Button Test Plan. [NAESB]

[ 71] Add tariff profile and service delivery point as optional addition to usage point The Green Button ESPI file format would benefit from the addition of a simple identifier (string) TariffProfile.name (and ServiceDeliveryPoint) from PAP10 identifying what tariff a customer is on. This addition would help to meet a need to simply ID customer rate plans as identified by CTO Todd Park's first "Energy Data Jam".

Comments:

Recommendation of OpenADE Task ForceRecommend NAESB extend ESPI to add TariffProfile.name and ServiceDeliveryPoint. [NAESB]

[ 72] Remark about test # FDFTP6 (related links matching self links)In the Green Button Test Cases.docx document, test # FDFTP6 says: Verify that all "related" atom link hrefs match the "self" link of another entry.

But "related" atom links need not always match a "self" link of an entry. They may also point to a related collection, e.g., a UsagePoint entry contains a "related" link to a collection of MeterReadings, and this "related" link matches the "up" links of the individual MeterReadings. (Each MeterReading has a different "self" link, but they all have the same "up" link.)

This affects also test # D.17, which is about the "up" links of MeterReadings and says: Verify that a valid value for the data element in the Test Purpose / Requirement (feed/entry[*/*:MeterReading]/link[@rel="up"]/@href) is present.

It follows from the above that the valid value of this @href is a "feed URL" for the collection of all MeterReadings, it does not match the "self" link of any other entry.

Comments:

Recommendation of OpenADE Task ForceSee resolution of help desk item 58 which summarizes best practice. [NAESB]

[ 73] Green Button test for stability of UUIDs neededThe Green Button Test Cases.docx document contains tests for the atom:ids, they must be UUIDs. An important aspect of these UUIDs not yet covered in the tests is that they must be stable, i.e., they must not change even if the same Green Button data is downloaded again at a later time.

For example, suppose I download my Green Button data today and it contains a MeterReading consisting of 5 IntervalBlocks (from January through May). Now suppose that I download my Green

Button data again next month, then it contains the same MeterReading, this time consisting of 6 IntervalBlocks (from January to June). Then I would expect the MeterReading UUID to be the same in both downloads, and also the first 5 IntervalBlocks to have the same UUIDs in both downloads.

Comments:

Recommendation of OpenADE Task ForceAdd Test FDFTP10 – Repeatable UUIDs. This test requests a UsagePoint resource; records the UUID; requests the UsagePoint resource again; verifies that the UUID is the same.

[74] Add additional UsageSummary structures for Gas and WaterCurrently, ElectricPowerUsageSummary contains summary information about past and present billing period usage. Additionally, there are some electricity-specific measures including peakDemand.

As ESPI is applied to Gas and Water, there may be additional summary attributes that apply to those utilities specifically. This update should accommodate them or perhaps make a more generic UsageSummary that supports a union of "dashboard" summary parts.

Comments:This topic is being considered by the new Gas WG in the SGIP.


[ 75] Logical Information Model components should be part of model

The logical information model annex of the ESPI standard contains data structures used by the abstract services. These should be the same model elements in the ESPI standard and schema. There needs to be reuse of the model and the missing components added to the model. [NAESB]

Comments:

Recommendation of OpenADE Task ForceUpdate the UML model accordingly.

[76] CSWG REQ 21 review - NISTIR 7628 ReferencesThe CSWG recommends that generic references to the National Institute of Standards and Technology (NIST) Interagency Report (IR) 7628, Guidelines for Smart Grid Cyber Security and ASAP-SG Security Profile for Third Party Access be removed. In place of the generic reference to NISTIR 7628, more in-depth security and privacy guidelines based on specific High-Level Security Requirements in the NISTIR 7628 should be provided in this or another document for the sensitive interactions between Energy Service Providers and other entities.

Comments:


[77] CSWG REQ 21 review - RFC 5849 OAuth 1.0The cybersecurity issues listed in Section 4 of RFC 5849 should be used as input for addressing some cybersecurity concerns for the interactions defined in the ESPI document.

Comments:


[78] CSWG REQ 21 review – TLS

The deprecated cryptography suites within TLS should be identified and not used. The list of deprecated suites should include, but is not limited to:

· TLS NULL_WITH_NULL_NULL · TLS_RSA_NULL_WITH_NULL_MD5 · TLS_RSA_NULL_WITH_NULL_SHA

Comments:(8/21/2012 2:52 PM): We need to know what we can use, in addition to what we can't.


[79] CSWG REQ 21 review – ReferencesNormative references to other documents should be provided as appropriate.

Comments:


[ 80] DateTimeInterval should make attributes optionalDateTimeInterval is used to fix interval data in time and duration. In the current standard these are required. However, when doing interval data at fixed intervals, and when the IntervalLength is specified in ReadingType, these timestamps are not necessary because they can be deduced from the stream of intervals in the IntervalBlock.

Thus, when the attributes of start and duration are optional, the encoding only needs to contain as much time information as necessary to clearly fix the start and end of each IntervalReading. The reduction in the extraneous tags allows for about a 50% reduction in the size of the data file.

Naturally, when the attributes are necessary to the purpose of the DateTimeInterval, they must be present.

Comments:

Recommendation of OpenADE Task ForceChange multiplicity of duration and start to optional. The DataCustodian must put a startTime value for each interval that begins a contiguous sequence. A duration must be provided for every interval that the duration deviates from the default IntervalDuration. Also need test cases for this. [NAESB]

[ 81] Modify UsagePoint/RoleFlags to match SEP2SEP2 specifies the following bit-field definitions. ESPI should map one-to-one to this list. ESPI has shifted the bit fields by one bit and SEP also has an additional item defined. Bit 0 - isMirror - SHALL be set if the server is not the measurement device Bit 1 - isPremisesAggregationPoint - SHALL be set if the UsagePoint is the point of delivery for a premises Bit 2 - isPEV - SHALL be set if the usage applies to an electric vehicle Bit 3 - isDER - SHALL be set if the usage applies to a distributed energy resource, capable of delivering power to the grid. Bit 4 - isRevenueQuality - SHALL be set if usage was measured by a device certified as revenue quality Bit 5 - isDC - SHALL be set if the usage point measures direct current Bit 6 - isSubmeter - SHALL be set if the usage point is not a premises aggregation point Bit 7-16 - Reserved

Comments:

Recommendation of OpenADE Task ForceThe bit identifications of ESPI should be normalized to the SEP 2.0 definitions. These bits are not substantially used in the early implementations and should be considered an error in the ESPI derivation since this came from SEP2.0 originally. [NAESB]

[ 82] How to communicate ‘greenness’ of Energy During an Interval (Scott.Crowder)Some consumers may want to change their consumption pattern to maximize their use of 'green' energy. Other consumers will want to change their consumption pattern to minimize their cost of energy.

The ESPI model already allows data custodians to provide an optional cost for each interval reading; that addresses the cost driven customers.

I would like to extend the model to allow an optional property of an interval reading to indicate the supplier's generation source fuel mix for each interval. This measure addresses the green energy driven customers.

Comments:Seems like a good idea. What are the issues about it?

How does this relate to the “business agreement”? Pricing and sources goes into a tariff. Then what happens when usage occurs? What is the greenness of the usage? Probably can’t determine the actual source of electrons, but can possibly attribute what the tariff says.

How do I know what source was actually used? If it is mixed, how do I represent the percentage? Green vs. LightGreen – variable percentage.

This does not need to be from the Data Custodian. For example, various service providers can attribute usage information and enrich the data set.

There is a concern that such characterization could be provided today. Therefore, this may be a futuristic requirement. Therefore, should it be made part of the current standard or is too early? Note: this could probably be provided today qualitatively but not necessarily verifiably.

How does this relate to “renewable energy certificates”?

Hypothetical solution: How you would characterize “greenness” – Perhaps a tagged enumeration, where enumerated “strings” are in ReadingType, and Intervals can be tagged with an index into the table. IntervalReading. Greenness with integer index into table?

3/12/2013 – Meeting Notes

Still concern about whether this is needed now. If the data did exist in a consistent and defined matter, it could be more actionable.

It is interesting but maybe not for specific implementation. Suggestion that it might be external as a realized as a mashup against the Green Button data. So an entity that knows this could provide the correlation with the EUI data.

Many other kinds of similar attributes might be of interest:

Greenness, what percent mix by generator, what is end use – e.g. EVs, appliance, ….

Recommendation of OpenADE Task ForceWe think this should a potential future enhancement for OpenADE and not implemented directly now.

[ 83] Add a PII element that is optional (jim.vezina, NREL)Generally we do not want to include PII information in the data feed, but it may be necessary. For example, in collecting data for analysis or aggregation, we would at least need the usage point (address). Today, PII information would be inserted into title fields or other fields. The problem then of course is it is difficult in identifying PII data since it could be anywhere - which makes anonymizing the data very difficult. I propose adding a new, optional element to the schema so if someone did need to include PII information, there was a specific place for it. And since there is a specific place for it, then it would be easy to remove as a step in anonymizing the data. Optional fields that come to mind are: usage point street address, city, state, zip, census block (as separate fields of course) account number account owner name (eg someone is downloading their data and we might want to have their name on it so they know for sure it's their data). and perhaps we could have generic attribute/value pair elements to handle other things (meter type, a special experimental cell they are part of, etc). So if there is additional meta data that is needed for a unique purpose, there would be a specific place in the XML for it to go.

Comments:Some comments from Don and Dave: They don’t like the concept of codifying “PII” in the spec because it could encourage its inclusion:

I don't like the proposal to codify PII; if we add it to the spec, it implies that it's OK to include PII in the data.[11:42:36 AM] David Mollerstuen: I'd suggest that those who want to include PII in the data define a standard (even de facto) "somwhere else", to allow the management of the PII as described in the help desk item.[11:43:09 AM] David Mollerstuen: That standard would "subclass" ESPI to add the fields described.[11:44:46 AM] David Mollerstuen: I suppose we could even do the work in NAESB ESPI (as an addendum or separate standard), but I don't like including optional PII in the actual ESPI spec.[11:45:00 AM] Donald F Coffin: I agree... such an addition would eliminate Privacy and consumer's trust of the information. I don't understand the need for PII so that the data can be anonymized[11:47:50 AM] David Mollerstuen: Yeah, agreed. Don't see enough benefit in the use case as described to warrant the risk of including optional fields for PII.

Concern from utilities about the data privacy. Clearly, the utility would not want to provide such information.

The biggest concern among the group is that this would make uncertain the statement which you can make today that ESPI ensures consumer privacy because it has no PII!

3/12/2013 meeting notes

Feeling that this is something to stay away from. Strong advice from SDG&E’s office of privacy.

While you can see the desire to include identity information somehow, there is a value in maintaining a clean separation between ESPI and PII. Let other forums or standards consider the linkage.

Should perhaps OpenADE start a separate effort about PII? Independent of ESPI?

Seems to be quite a consensus around keeping PII out of ESPI.

There could be a concept of aggregating Green Button data so that detail is removed.

Recommendation of OpenADE Task ForceWe consider completing the current round of ESPI updates and perhaps consider a secondary and separate effort to capture PII.

[84] Scope Selection page on Data Custodian site vs 3rd Party Site Per the GreenButtonAuthorization.doc storyboard etc., requesting the Scope Selection page be moved (mandatory and/or optional) to the Data Custodian site as opposed to the 3rd party site.

Concerns as far as how the 3rd party knows what scope of data elements etc. would be provided by Data Custodian for GBCMD. Also, would prefer such options live with Data Custodian in the event the scope of data elements could change in the future (e.g. Data Custodian adds new data elements for sharing etc.).

Comments:


[85] Time of Use tier indicator alignment with SEP 2.0 The ToU tier indicator is currently captured at the ReadingType level - this can require multiple ReadingType changes when a Usage Point transitions between tariffs and complicates the data model. It

would be preferable to constrain the ReadingType to representing the technical details of the Meter Reading (somewhat equivalent to the register of a meter). Moving the ToU tier indicator to the IntervalReading level would provide a simpler model for representing this information and would align with how this is represented in SEP 2.0

Comments:


[86] Proposal for Green Button Security/Privacy EnhancementCurrently, Green Button schema does not accommodate digital signature for integrity protection. Thus, a service provider who works on the Green Button data presented by a electricity customer has no way to verify the authenticity of data (i.e. whether the data is really the data issued by a utility company or not). Lack of such verifiability could limit the range of Green Button data utilization. The reasonable solution for this problem is to embed utility's digital signature into Green Button so that any third party service provider can verify it. On the other hand, at the same time, it is desired for electricity customers to flexibly redact some portion of the Green Button data for the sake of their privacy, without losing the validity of the utility's signature. To address both properties, we propose to integrate redactable digital signature scheme into Green Button. (See the attached paper presented at ACM Smart Energy Grid Security workshop in 2013 for detail. http://osgug.ucaiug.org/HelpDesk/Lists/servicerequests/Attachments/86/segs-draft.pdf )

Comments:


[88] Change title of ElectricPowerUsageSummary to UsageSummary and extend As Green Button gets used for more than electricity -- i.e. gas and water. As the usage summary resource gets used for billing details, a set of clarifications and extensions are needed.

From PG&E:

As ESPI designates RESTful web services for exchange of data, the concept of “current”, “last” and “previous” is not suitable for ESPI objects. For example, if a 3rd party requests data for a 6 month date range, what is considered “last period” or “previous day”? This ambiguity does not fit with the other provided objects in ESPI.

We propose instead to make the billing period specific to the 3rd party requested and/or data custodian provided date range of data. For a 3rd party request that spans several billing periods, the UsageSummary will return data for whatever bill periods have bill information available. For example, if a request is made that spans 3 historical billing periods, for which 2 of the billing period usage summaries are available at the time of the request, then usage summaries for the 2 bill periods will be provided.

http://osgug.ucaiug.org/HelpDesk/Lists/servicerequests/Attachments/86/segs-draft.pdf

To avoid 3rd parties having to know in advance a customer’s billing period, requests only need to overlap with a day within that billing period to return the related usage summary (i.e. request does not need to cover the entire billing period to be valid). It is at the discretion of the data custodian for how to handle authorization. For example, at the time of customer authorization, the data custodian and/or 3rd party can choose to put the responsibility on the customer in so far as understanding that authorization of bill summary information means sharing bill information for any of the authorized usage date range. For example, if a bill spanned from 1/15 to 2/15, and the customer authorized sharing of usage data only starting on 2/1, then a request for bill usage information for February could include sharing information from 1/15-1/31. Alternatively, the Data Custodian could implement additional logic to prevent such a scenario.

Batch requests (i.e. all objects underneath Usage Point, including MeterReading, IntervalBlock etc.) will return available bill amount info pertaining to the requested date range as prescribed above. Individual requests for usage summaries only, will behave similar to batch as far as date logic, however will return usage summaries only. Daily batch subscription files, whereby only the latest day’s usage is provided, will provide UsageSummaries only as that data becomes available to the Data Custodian to publish. from

Marty:

To preserve backwards compatibility we agreed in OpenADE to:

1) Create new UsageSummary (which is NAESB REQ.18 name)

2) Add new tags recommended by PG&E

3) Retain all existing tags and make UsageSummary and ElectricPowerUsageSummary identical – but mark old one deprecated for backwards compatibility – new implementations will have to accept either Resource on input

4) Revise descriptions of existing tags to make clear what goes with billing period etc.

5) Provide documentation on how to interpret query parameters for GET UsageSummary

Comments:

Recommendation of OpenADE Task ForceAdd enumerated value to QualityOfReading:

<xs:enumeration value="19"> <xs:annotation> <xs:appinfo>revenue-quality</xs:appinfo> <xs:documentation>data that is valid and acceptable for billing purposes</xs:documentation> </xs:annotation></xs:enumeration>

This allows various aspects of data to be tagged this way.

[89] ESPI Schema extension: Revenue Quality value for Quality of Reading Flag This request is to document and formalize prior discussions between varying parties (e.g. CPUC, California IOUs etc.) including on the OpenADE weekly forum (i.e. 5/20/14 discussion).

To meet requirements around indicating to 3rd parties whether usage data is 'revenue quality' or not, we would like to add a new possible value for the Quality of Reading flag (e.g. 19), to indicate the provided usage data is "Revenue Quality: valid and acceptable for billing purposes".

Comments:

Recommendation of OpenADE Task ForceAdd

[90] Error in GB TestPlan: FB_07,08 AccumulcationBehavior should be 4As reported by SDG&E, the test cases D074,D075, and D076 are currently testing for a value of 1 and it should be 4. According to the definitions in the schema:

Value of 1: A value from a register which represents the bulk quantity of a commodity. This quantity is computed as the integral of the commodity usage rate. This value is typically used as the basis for the dial reading at the meter, and as a result, will roll over upon reaching a maximum dial value. Note 1: With the metering system, the roll-over behaviour typically implies a roll-under behaviour so that the value presented is always a positive value (e.g. unsigned integer or positive decimal.) However, when communicating data between enterprise applications a negative value might occur in a case such as net metering. Note 2: A BulkQuantity refers primarily to the dial reading and not the consumption over a specific period of time.

Value of 4: The difference between the value at the end of the prescribed interval and the beginning of the interval. This is used for incremental interval data. Note: One common application would be for load profile data, another use might be to report the number of events within an interval (such as the number of equipment energizations within the specified period of time.) To correct, change 1 to 4 in three tests.

Recommendation of OpenADE Task ForceThis proposal was reviewed and accepted by the OpenADE Task force in its meeting on 3/31/2015

[91] Error in Test Plan: FB_04 For Interval Metering, FB_04, the file is tested for the existence of a MeterReading corresponding to each ReadingType. This is backwards in that there should be a reading type for each MeterReading. Implementations in the field have suggested that they prefer to have the typically small set of ReadingTypes in use in each GreenButton data set and this should be permitted even if it is not used within the data set.

Recommendation of OpenADE Task ForceThis proposal was reviewed and accepted by the OpenADE Task force in its meeting on 3/3/2015

[92] Need to include <link> reference to Certification ID

Comments:Add Atom link to each data stream/file to allow consumers of the data (third party tools or individuals) to find provenance and detail of the certification.

Recommendation of OpenADE Task ForceAdd test for the presence of a link to the certification record as part of FB_01. Link of the form: https :// cert.greenbuttonalliance.org/92348981231 , suitable for a REST retrieval via GET.

[93] Customers have requested access to the Green Button CMD API interface to access their own account informationLarge customers have requested to be able to access their energy usage information via the Green Button Connect My Data API interface. Although the current CMD API definitions only envisioned Third Parties accessing their customer's energy usage information, this does not seem to be an unreasonable request.

Comments:Correllary: Authorizing a handheld app to access customer data via GBCMD.


[94] Inclusion of Read Cycle to Usage Point and Usage Summary

Comments:Requesting importing 'ReadCycle' element from Common Info Model (under Usage Point) to ESPI's Usage Point and Usage Summary. This data element (string) addresses representation of the meter reading periods. In addition to inclusion under Usage Point, also requesting inclusion in Usage Summary so as to potentially represent history of Meter Read Cycle if needed, whereby it may change occasionally from bill to bill.

Additional Info on California Utilities' different Meter Read Schedules can be found on their respective websites.

https://cert.greenbuttonalliance.org/92348981231




[95] Green Button Download My Data Gas Function Block [FB_10] only allows "therms" UOMType = 169

Comments:The current Green Button Download My Data (DMD) Gas Interval Data certification test only supports a value of 169 (Therm) for the UOMType when the CommodityType value is 7 (Natural Gas). Countries on the metric system often use a metric based measurement of m3/h (Cubic Meter per Hour) which is defined as UOMType value 125. The Green Button Download My Data Gas Function Block [FB_10] should allow either 7 or 125 as certifiable UOMType values for CommodityType 7 (NaturalGas).

From OpenADE Mail List:

Let me summarize what I heard so far:

1) Gas is reported/billed in therm (US), ft3 (US), m3, joule primarily. Other UOMs differ by power of 10 multiplier managed separately in ReadingType

2) Only therm and joule actually measure energy. The others measure volumes and must be converted to energy based on a continually varying constant based on the correspondingly varying gas composition.

3) In the case of volume, the volume is often the billing quantity with the energy content reported alongside after conversion

4) The volume to energy conversion is based on a constant multiplier j/m3 that is computed and reported typically monthly.

Further:

5) Commodity =7 for natural gas and =8 for propane.6) MeasurementKind does not have descriptors that would be useful for natural gas such as that

the volume is represented at STP (standard temperature and pressure), or, indicating a gas heat content value measurement. This could be a useful extension of the enumeration.

Finally:

7) In order to represent the changing value of the conversion factor between volume and energy, a separate instance of ReadingType and series of timestamped readings could be used to provide the record of these conversions. Thus if gas usage is reported in volume, an additional measurement set would be required to convey the set of values over time.

Recommendation of OpenADE Task Force1) The required acceptance of therm (US), ft3 (US), m3, joule for gas2) If reporting volume, the optional inclusion of a separate MeterReading, ReadingType, and

IntervalBlocks for reporting the conversion constant.

[96] Green Button Download My Data Water Function Block [FB_11] only allows UOMType = 128 (US gl (US Gallons)

Comments:The current Green Button Download My Data (DMD) Water Interval Data certification test only supports a value of 128 (US gl (US Gallons)) for the UOMType when the CommodityType value is 11 (Waste/Water). Countries on the metric system often use a metric based measurement of m3/h (Cubic Meter per Hour) which is defined as UOMType value 125. The Green Button Download My Data Gas Function Block [FB_11] should allow either 128 or 125 as certifiable UOMType values for CommodityType 11 (Waste/Water).

Recommendation of OpenADE Task ForceWater units of measure accepted include support ft3 (US), m3, and US gallons.

[97] Update UsagePoint for 61968-9 2nd edition elements

Comments:For SCE & PGE: There are some identifiers associated with UsagePoints that are valuable and were added to the CIM model after the NAESB PAP10/ESPI snapshots were made.

We should add these attributes because they are valuable in supporting California and likely other jurisdictions DSM efforts


[xx] title

Comments:
