1 / 175

OpenADE Meeting Notes - April 4, 2017

This document provides the agenda and discussions from the OpenADE meeting held on April 4, 2017. Topics include data custodian certification tasks, connect my data compliance requirements, and future certification testing.

keving
Download Presentation

OpenADE Meeting Notes - April 4, 2017

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Weekly OpenADE Meeting Notes Tuesday, April 4, 2017

  2. April 4, 2017 -- Agenda • Review Data Custodian Connect My Data FIPS 140-2 Compliance Requirements • Future Connect My Data Certification Testing – Third Party Connect My Data Certification Tasks • Third Party a subset of the DC CMD Mandatory Function Blocks – [FB_22] Security and Privacy Classes – [FB_23] Authorization and Authentication » A) With pre-negotiated Scope » B) [Future] Without pre-negotiated Scope [FB_xx] • Third Parties must verify compliance with API formats

  3. April 4, 2017 -- Agenda – Data Custodian Connect My Data Retail Customer Certification Tasks • Function Blocks – [FB_46] Core RetailCustomer – [FB_47] REST for RetailCustomer Bulk – [FB_48] SFTP for RetailCustomer Bulk – [FB_49] RetailCustomer Management REST – [FB_50] RetailCustomer Resource Level REST – Do we need to add a Function Block for 3rdParty Retail Customer posting for DRAM program? • General Test Requirements – Comply with Green Button Retail Customer Schema – Third Party Authorization Management Capabilities

  4. March 28, 2017 -- Agenda • Data Custodian CMD Function Block 08 – Forward and Reverse Metering Test Requirements – Current test requires both Forward and Reverse Meter Reading to be present to pass • Current recommendation is that FB_08 should ONLY test for Reverse Flow direction • Finalize during next OpenADE conference call • The Task Force agreed that FB_08 should ONLY test for Reverse Meter data – Assign Function Block for Authorization w/o Pre-Scope Negotiation • Next Available Function Block is [FB_31] • The Task Force agreed to use Function Block [FB_31] – Review Data Custodian Connect My Data FIPS 140-2 Compliance Requirements • Future Connect My Data Certification Testing – Third Party Connect My Data Certification Tasks – Data Custodian Connect My Data Retail Customer Certification Tasks

  5. March 21, 2017 -- Agenda • Data Custodian CMD Function Block 08 – Forward and Reverse Metering Test Requirements – Current test requires both Forward and Reverse Meter Reading to be present to pass • Current recommendation is that FB_08 should ONLY test for Reverse Flow direction • Finalize during next OpenADE conference call • Future Connect My Data Certification Testing – Third Party Connect My Data Certification Tasks – Data Custodian Connect My Data Retail Customer Certification Tasks

  6. March 14, 2017 -- Agenda • Data Custodian CMD Function Block 08 – Forward and Reverse Metering Test Requirements – Current test requires both Forward and Reverse Meter Reading to be present to pass • Current recommendation is that FB_08 should ONLY test for Reverse Flow direction • Finalize during next OpenADE conference call • Future Connect My Data Certification Testing – Third Party Connect My Data Certification Tasks – Data Custodian Connect My Data Retail Customer Certification Tasks

  7. March 7, 2017 -- Agenda • HelpDesk #98 – Alternative Oauth Flow for ESPI to align with Oauth 2.0 Specification – California CPUC requires OAuth 2.0 authorization_code flow meet Oauth 2.0 RFC 6749 specifications • Current Data Custodian Connect My Data Certification test harness currently meets this requirement • At question is should the current Data Custodian Connect My Data Certification test harness make Third Party/Data Custodian Scope negotiation optional and thus require changes to the test case requirements and test steps • The Task Force decided that the Data Custodian Connect My Data certification test harness MUST provide the ability to be certified using the current Scope Selection Screen flow and the Oauth 2.0 authorization_code flow without accessing the Scope Selection Screen endpoint HelpDesk #98 – Is the current definition of authorizedPeriod sufficient? – The current definition of authorizedPeriod (found in the ESPI authorization structure) is UINT32, which supports 4,294,967,295 seconds. Some Data Custodians are setting "infinite" expiration periods that exceed this maximum value. • The Task Force decided to enforce the current UINT32 definition and ensure Data Custodians use an end date that does not exceed the UINT32 capacity • How should a Data Custodian indicate an “infinite” period? – The Task Force decided to indicate a value of “0” in the authorizedPeriod represents an infinite authorization period as part of the ESPI Redline revision. •

  8. <ns1:entry> <ns1:id xsi:type="ns1:idType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">bed0b17a-6712-40f4-96a1- 487ca6a75244</ns1:id> <ns1:link href="https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Authorization" rel="up" xsi:type="ns1:linkType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> <ns1:link href="https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Authorization/420091" rel="self" xsi:type="ns1:linkType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> <ns1:published xsi:type="ns1:dateTimeType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">2017-02- 08T16:37:40.701Z</ns1:published> <ns1:updated xsi:type="ns1:dateTimeType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">2017-02- 08T16:37:40.702Z</ns1:updated> <ns1:content xsi:type="ns1:contentType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ns0:Authorization xmlns:ns0="http://naesb.org/espi"> <ns0:authorizedPeriod> <ns0:duration>251,915,702,400</ns0:duration>4,294,967,295 <ns0:start>1486540800</ns0:start> </ns0:authorizedPeriod> <ns0:publishedPeriod> <ns0:duration>251978860800</ns0:duration> <ns0:start>1423382400</ns0:start> </ns0:publishedPeriod> <ns0:status>1</ns0:status> <ns0:expires_at>1486575162</ns0:expires_at> <ns0:scope>FB=1_3_8_13_14_18_19_31_32_35_37_38_39_40_4_15_10_46_47_16_5;IntervalDuration=900_3600;BlockDuration=D aily;HistoryLength=63072000;SubscriptionFrequency=Daily;AccountCollection=1;BR=50036;</ns0:scope> <ns0:token_type>Bearer</ns0:token_type> <ns0:resourceURI>https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Subscription/420091</ns0:resourceURI> <ns0:authorizationURI>https://api.pge.com/GreenButtonConnect/espi/1_1/resource/Authorization/420091</ns0:authoriz ationURI> </ns0:Authorization> </ns1:content> </ns1:entry>

  9. March 7, 2017 -- Agenda • Future Connect My Data Certification Testing – Third Party Connect My Data Certification Tasks – Data Custodian Connect My Data Retail Customer Certification Tasks

  10. February 28, 2017 -- Agenda • Should Certification Test verify Data Custodian only sends data authorized by retail customer? – Group agreed the Certification test should verify Data Custodian interval data must meet Scope FB definitions authorized by retail customer. What data should be returned for /resource/Subscription/{subscriptionId}/UsagePoint/{usagePointId}/Meter Reading/ – Only MeterReading elements will be returned – Should DC CMD Test Harness check non-batch API implementations HelpDesk #98 – Alternative Oauth Flow for ESPI to align with Oauth 2.0 Specification – California CPUC requires OAuth 2.0 authorization_code flow meet Oauth 2.0 RFC 6749 specifications • Current Data Custodian Connect My Data Certification test harness currently meets this requirement • At question is should the current Data Custodian Connect My Data Certification test harness make Third Party/Data Custodian Scope negotiation optional and thus require changes to the test case requirements and test steps • •

  11. February 28, 2017 -- Agenda • Future Connect My Data Certification Testing – Third Party Connect My Data Certification Tasks – Data Custodian Connect My Data Retail Customer Certification Tasks

  12. CPUC Rule 24: One-Click • Has there been a CPUC Final Ruling? – Yes. – Authorizations must start and finish on the Third Party website – CPUC has agreed IOUs can implement authorization via OAuth 2.0 • Does CPUC require Data Custodian’s to grant multiple Third Parties Access Tokens with One Customer Authorization • How should “Super” Third Party access tokens be assigned – “Super” Third Party is a Third Party that retrieves Energy Usage Information on behalf of their Third Party customer (i.e. Utility API model)

  13. CPUC Appendix E – DRP Requirements for Solution 3 • OAUTH improvements 1. Support authorizations to 2 or more DRPs for the same customer at the same time • Needs further investigation and discussion 2. The url that DRP redirects the user to should be the OAuth authorize url (as defined in OAuth 2.0 specification). • Requires a new optional Certification Function Block (FB) to verify IOU does not require DRP authorizations to access ESPI ScopeSelectionScreen endpoint 3. The IOU only redirects to authentication interface if needed, then redirects back to the original OAuth authorization url

  14. CPUC Appendix E – DRP Requirements for Solution 3 4. Authentication interface must be skipped if user already has valid authentication session cookie 5. Authentication interface must be able to allow password resets/reminders and still remain in authorization flow 6. Authentication interface must be able to allow login credentials as authentication fields 7. Authentication interface must have alternative instant authentication for users without logins (account# + zip, etc.)

  15. CPUC Appendix E – DRP Requirements for Solution 3 8. Best case authorization interface must be 1-click “Authorize” button 9. Default is all services are pre-selected and customer has to un-select the ones they want to exclude 10.Redirected back to DRP with code after clicking “Authorize”, no confirmation page on IOU 11.Valid implementation of OAuth 2.0 Code Grant Flow per https://tools.ietf.org/html/rfc6749#section-4.1.

  16. CPUC Appendix E – DRP Requirements for Solution 3 12.Authorize url meets OAuth 2.0 spec per https://tools.ietf.org/html/rfc6749#section- 4.1.1. • Additional value= parameters need to be allowed for IOU DRP specific information • Additional optional Function Block testing for DRP support needs to be added to the current CMD certification test suite 13.Be able to handle state parameters, even through authentication interface.

  17. CPUC Appendix E – DRP Requirements for Solution 3 13. Be able to register multiple redirect_uris with IOUs so that DRPs can have testing/staging/production redirect_uris 15. Be able to handle re-authorization for new code grant if DRP has lost previous code or access_token • Requires addition of test script to confirm Data Custodian meets above requirement. 16. Be able to handle a user declining to authorize a DRP in both authentication and authorization interface. 17. Be able to redirect errors back to the DRP per https://tools.ietf.org/html/rfc6749#section-4.1.2.1

  18. Query Parameters • Atom – published -- represents the time stamp when the containing entry was created – updated – represents the time stamp when the containing entry was changed • Original Intent – Required: query using published_min,max – allows search of IntervalBlocks that contain intervals between min and max • Does this require correct values for published in atom or just that the query parameters are properly interpreted?

  19. Query Parameter Requirements – From GreenButtonAuthorization.docx

  20. Current Implementations • LH – published timestamp is the end of the first interval in the IntervalBlock PGE – published timestamp is the moment of creation of the XML result Query parameters published_min/max must be interpreted in the context of the IntervalBlocks which is the data actual being sought by the query Certification Test Algorithm: 1. Test Harness performs an authorization on the test account 2. Test account must have 4 or more interval blocks of data 3. Test Harness does GET on resourceURI returning subscription with “n” IntervalBlocks 4. Test Harness does GET on resourceURI with 1. published_min equal to the IntervalBlock.start time of the 2ndIntervalBlock returned in step 3 2. published_max equal to the IntervalBlock.start time (n-1)thIntervalBlock returned • • •

  21. Initial Third Party Test Requirements – very rough [FB_20] Common Common configuration data exchange [FB_21] Connect My Data Support Application Info request or other similar from FB_03 Support notification reception [FB_22] Security and Privacy Classes Support the TP version of FB_13 (relaxes from TLS 1.2 to TLS 1.1, I don’t know if there is anything else different). [FB_23] Authorization and Authentication Perform the client side of OAuth [FB_24] Request Bulk UsagePoints If supported, receive a Notification and to an bulk GET or SFTP GETALL [FB_25] Request Partial Update Data No initial tests required [FB_26] Properly Respond to Various Bad or Missing Data Perform authorization, TP performs GET of resourceURI, provide several examples of bad data [FB_42] Core REST Services No initial tests required

  22. Older or other slides Will build deck with new content over time.

  23. Topics • Service Request 95 – Green Button Download My Data Gas Function Block [FB_10] only allows "therms" UOMType = 169 Permit therms, joules, ft3, m3 expand acceptance of test Optionally if you have volume, add MeterReading, ReadingType, and IntervalBlock for convervion factor history Service Request 96 – Green Button Download My Data Water Function Block [FB_11] only allows UOMType = 128 (US gl (US Gallons) Permit US Gallons, ft3, and m3 expand acceptance of test Service Request 97 – Update UsagePointfor 61968-9 2nd edition elements Service Request 83 – including Function Block for optional customer info (service point address, etc.) – retailcustomer.xsd • Updated schema – espiderived.xsd • LSE, MDMA, MSP identification • Sub-LAP and LCA • planning bus and a market operations bus? – Accept API and FBs – Generate Test Requirements espiderived.xsd – Updated UsagePoint Populating UsageSummary bill elements Query Parameter Testing for FB_37 Testing Requirements for Third Parties • • • • • • • • • • • Tariff Model Resource

  24. Support of Aggregate References • Sub-LAP (associated with parent LAP) – ApnodeType=LAP(Load Aggregation Point) as a child of aggregateNodeRef • LAP Load Aggregation Point – AnodeType=ALR(Aggregate Load Resource) • LCA - Load Capacity Area – ApnodeType=CA(Control Area) • planning bus – ApnodeType=BUS • market operations bus – ApnodeType=BUS

  25. CIM UML Model of Aggregates class Aggregate... class Aggregate... «enumeration» MktDomain:: AnodeType class AggregateNode class AggregateNode MktDomain:: AnodeType +RTO MktOrganisation RTO 1 SYS RUC LFZ REG AGR POD ALR LTAC ACA ASR ECA RTO +RTO 0..1 RUCZone RUCZone +RTO 1 +AggregateNode 0..* IdentifiedObject LoadAggregationPoint LoadAggregationPoint AggregateNode AggregateNode + anodeType: AnodeType [0..1] + endEffectiveDate: DateTime [0..1] + qualifASOrder: Integer [0..1] + startEffectiveDate: DateTime [0..1] MarketRegion MarketRegion 0..1 +AggregateNode class Apnode class Apnode +AggregateNode 0..* 0..* +AggregateNode «enumeration» MktDomain:: ApnodeType MktDomain:: ApnodeType 0..* +CnodeDistributionFactor IdentifiedObject AG CPZ DPZ TH SYS CA DCA GA GH EHV ZN INT BUS +RegisteredResources +RegisteredResource 0..* CnodeDistributionFactor CnodeDistributionFactor 0..* +Pnode PowerSystemResource MarketCommon:: RegisteredResource +RegisteredResource + factor: Float [0..1] + podLossFactor: Float [0..1] IdentifiedObject Pnode +Pnode MarketCommon:: RegisteredResource Pnode 0..* 0..* 0..1 +Pnodes 0..* 0..* +CnodeDistributionFactor +MktConnectivityNode RegisteredGenerator RegisteredGenerator RegisteredLoad RegisteredLoad AggregatedPnode AggregatedPnode +MktConnectivityNode 1 0..* ConnectivityNode MarketOpCommon:: MktConnectivityNode +MktConnectivityNode MarketOpCommon:: MktConnectivityNode IndividualPnode IndividualPnode RegisteredInterTie RegisteredInterTie 0..1 1 +IndividualPnode +MktConnectivityNode 0..1

  26. espiderived.xsd extension of UsagePoint

  27. Sample XML <?xml version="1.0" encoding="UTF-8"?> <UsagePoint xmlns="http://naesb.org/espi" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://naesb.org/espi espiDerived.xsd"> <ServiceCategory> <kind>1</kind> </ServiceCategory> <pnodeRefs> <pnodeRef> <apnodeType>BUS</apnodeType> <ref>reference to a bus</ref> </pnodeRef> </pnodeRefs> <aggregateNodeRefs> <aggregateNodeRef> <anodeType>ALR</anodeType> <ref>reference to an aggregate load resource</ref> <pnodeRef> A pnode that is a bus reference A LAP Aggregate with a SUB-LAP pnode reference <apnodeType>LAP</apnodeType> <ref>reference to an sub aggregated load</ref> </pnodeRef> </aggregateNodeRef> </aggregateNodeRefs> </UsagePoint>

  28. Pnodes and AggregateNodes <pnodeRefs> <pnodeRef> <apnodeType>LAP</apnodeType> <ref>https://fubar.com/espi/1_1/resources/pnodes/aggregatePnodes/12345656</ref> </pnodeRef> </pnodeRefs> <aggregateNodeRefs> <aggregateNodeRef> <anodeType>SYS</anodeType> <ref>https://fubar.com/espi/1_1/resources/aggregateNodes/LoadAggregationPoints/2468ef2</ref> </aggregateNodeRef> </aggregateNodeRefs>

  29. Some DC Procedures • PGE: – http://www.pge.com/en/myhome/addservices/sh aremydata/authorized/api/testing/index.page? – http://www.pge.com/en/myhome/addservices/sh aremydata/authorized/getstarted/index.page? • <<need to collect from SDG&E, SCE, and LondonHydro>>

  30. Pnode/AggregationPoints from CIM Model class AggregateNode class AggregateNode +RTO MktOrganisation RTO 1 RTO +RTO 0..1 RUCZone RUCZone +RTO 1 +AggregateNode 0..* IdentifiedObject LoadAggregationPoint LoadAggregationPoint AggregateNode AggregateNode + anodeType: AnodeType [0..1] + endEffectiveDate: DateTime [0..1] + qualifASOrder: Integer [0..1] + startEffectiveDate: DateTime [0..1] MarketRegion MarketRegion 0..1 +AggregateNode +AggregateNode 0..* 0..* +AggregateNode 0..* +CnodeDistributionFactor IdentifiedObject +RegisteredResources +RegisteredResource 0..* CnodeDistributionFactor CnodeDistributionFactor 0..* +Pnode PowerSystemResource MarketCommon:: RegisteredResource +RegisteredResource + factor: Float [0..1] + podLossFactor: Float [0..1] IdentifiedObject Pnode +Pnode MarketCommon:: RegisteredResource Pnode 0..* 0..* 0..1 +Pnodes 0..* 0..* +CnodeDistributionFactor +MktConnectivityNode RegisteredGenerator RegisteredGenerator RegisteredLoad RegisteredLoad AggregatedPnode AggregatedPnode +MktConnectivityNode 1 0..* ConnectivityNode MarketOpCommon:: MktConnectivityNode +MktConnectivityNode MarketOpCommon:: MktConnectivityNode IndividualPnode IndividualPnode RegisteredInterTie RegisteredInterTie 0..1 1 +IndividualPnode +MktConnectivityNode 0..1

  31. UsagePoint Associations that will add the needed elements class CustomersOverview class CustomersOverview IdentifiedObject Metering::UsagePoint Metering::UsagePoint + isSdp: Boolean [0..1] + isVirtual: Boolean [0..1] + phaseCode: PhaseCode [0..1] + grounded: Boolean [0..1] + servicePriority: String [0..1] + serviceDeliveryRemark: String [0..1] + estimatedLoad: CurrentFlow [0..1] + checkBilling: Boolean [0..1] + ratedCurrent: CurrentFlow [0..1] + nominalServiceVoltage: Voltage [0..1] + ratedPower: ActivePower [0..1] + outageRegion: String [0..1] + readCycle: String [0..1] + readRoute: String [0..1] + amiBillingReady: AmiBillingReadyKind [0..1] + connectionState: UsagePointConnectedKind [0..1] + minimalUsageExpected: Boolean [0..1] «enumeration» MktDomain:: AnodeType MktDomain:: AnodeType SYS RUC LFZ REG AGR POD ALR LTAC ACA ASR ECA 0..* 0..* +UsagePoints +UsagePoints +AggregateNodes 0..* +Pnode 0..1 IdentifiedObject IdentifiedObject ReferenceData::AggregateNode ReferenceData::AggregateNode ReferenceData::Pnode ReferenceData::Pnode +Pnode +AggregateNode + anodeType: AnodeType [0..1] + endEffectiveDate: DateTime [0..1] + qualifASOrder: Integer [0..1] + startEffectiveDate: DateTime [0..1] + endEffectiveDate: DateTime [0..1] + isPublic: Boolean [0..1] + startEffectiveDate: DateTime [0..1] 0..* 0..*

  32. AnodeTypes for Aggregate Nodes • • - SYS - System Zone/Region; - RUC - Reliability Unit Commitment Zone; – A specialized class of type AggregatedNode type. Defines RUC Zones. A forecast region represents a collection of Nodes for which the Market operator has developed sufficient historical demand and relevant weather data to perform a demand forecast for such area. The Market Operator may further adjust this forecast to ensure that the Reliability Unit Commitment produces adequate local capacity procurement. - LFZ - Load Forecast Zone; - REG - Market Energy/Ancillary Service Region; - AGR - Aggregate Generation Resource; - POD - Point of Delivery; - ALR - Aggregate Load Resource; - LTAC - Load Transmission Access Charge (TAC) Group; - ACA - Adjacent Control Area - ASR - Aggregated System Resource - ECA - Embedded Control Area • • • • • • • • • • LoadAggregatinPoint(ALR?), SubLoadAggregationPoint (ECA?), ICAP or LocalCapacityArea (SYS?) are in this list or need to be explicitly added.

  33. Resulting XML Schema For UsagePoint Enhancements XML XMLSchema (at end of UsagePoint)

  34. RetailCustomer Model Identities for Rule 24 class RetailCustomer class RetailCustomer class RetailCustomer class RetailCustomer «Enumeration» PaymentMetering: :SupplierKind PaymentMetering: :SupplierKind PaymentMetering::ServiceSupplier PaymentMetering::ServiceSupplier + kind: SupplierKind [0..1] + issuerIdentificationNumber: String [0..1] utility retailer other lse mdma msp Meter Multipliers class RetailCustomer class RetailCustomer class RetailCustomer class RetailCustomer «Enumeration» Metering:: MeterMultiplierKind Metering:: MeterMultiplierKind +Meter Metering::Meter Metering::Meter kH kR kE ctRatio ptRatio transformerRatio + formNumber: String [0..1] Metering::MeterMultiplier Metering::MeterMultiplier 0..1 0..* + kind: MeterMultiplierKind [0..1] + value: Float [0..1] +MeterMultipliers

  35. Retail Customer class RetailCustomer class RetailCustomer IdentifiedObject Common:: OrganisationRole IdentifiedObject IdentifiedObject Common:: OrganisationRole +Roles Common::Document Common::Document Common::Organisation Common::Organisation +Organisation 0..* + type: String [0..1] + authorName: String [0..1] + createdDateTime: DateTime [0..1] + lastModifiedDateTime: DateTime [0..1] + revisionNumber: String [0..1] + electronicAddress: ElectronicAddress [0..1] + subject: String [0..1] + title: String [0..1] + docStatus: Status [0..1] + status: Status [0..1] + comment: String [0..1] + streetAddress: StreetAddress [0..1] + postalAddress: StreetAddress [0..1] + phone1: TelephoneNumber [0..1] + phone2: TelephoneNumber [0..1] + electronicAddress: ElectronicAddress [0..1] 0..1 Common::Agreement Common::Agreement PaymentMetering::ServiceSupplier PaymentMetering::ServiceSupplier + signDate: Date [0..1] + validityInterval: DateTimeInterval [0..1] + kind: SupplierKind [0..1] + issuerIdentificationNumber: String [0..1] Customers:: CustomerAccount Customers:: CustomerAccount Customers::Customer Customers::Customer Customers:: CustomerAgreement Customers:: CustomerAgreement + kind: CustomerKind [0..1] + specialNeed: String [0..1] + pucNumber: String [0..1] + status: Status [0..1] + priority: Priority [0..1] + locale: String [0..1] «deprecated» + vip: Boolean [0..1] + billingCycle: String [0..1] + budgetBill: String [0..1] + lastBillAmount: Money [0..1] + loadMgmt: String [0..1] + isPrePay: Boolean [0..1] + shutOffDateTime: DateTime [0..1] +CustomerAgreements 0..* +CustomerAgreements 0..* +PricingStructures0..* +DemandResponsePrograms 0..* Customers:: PricingStructure Customers:: PricingStructure Metering::DemandResponseProgram Metering::DemandResponseProgram IdentifiedObject Common::Location Common::Location + type: String [0..1] + mainAddress: StreetAddress [0..1] + secondaryAddress: StreetAddress [0..1] + phone1: TelephoneNumber [0..1] + phone2: TelephoneNumber [0..1] + electronicAddress: ElectronicAddress [0..1] + geoInfoReference: String [0..1] + direction: String [0..1] + status: Status [0..1] IdentifiedObject Assets::Asset Assets::Asset + type: String [0..1] + utcNumber: String [0..1] + serialNumber: String [0..1] + lotNumber: String [0..1] + purchasePrice: Money [0..1] + critical: Boolean [0..1] + electronicAddress: ElectronicAddress [0..1] + lifecycle: LifecycleDate [0..1] + acceptanceTest: AcceptanceTest [0..1] + initialCondition: String [0..1] + initialLossOfLife: PerCent [0..1] + status: Status [0..1] Work:: Work:: WorkLocation WorkLocation Assets:: AssetContainer Assets:: AssetContainer Customers::ServiceLocation Customers::ServiceLocation + accessMethod: String [0..1] + siteAccessProblem: String [0..1] + needsInspection: Boolean [0..1] +ServiceLocation 0..1 +UsagePoints Metering:: UsagePoint Metering:: UsagePoint 0..* Metering::EndDevice Metering::EndDevice + isVirtual: Boolean [0..1] + isPan: Boolean [0..1] + installCode: String [0..1] + amrSystem: String [0..1] Metering::Meter Metering::Meter +Meter +MeterMultipliers + formNumber: String [0..1] Metering::MeterMultiplier Metering::MeterMultiplier 0..1 0..* + kind: MeterMultiplierKind [0..1] + value: Float [0..1]

  36. class RetailCustomer class RetailCustomer Minor Classes and Enums «Compound» Common::Status «Enumeration» «Compound» Common::TownDetail Common::Status Customers::CustomerKind Customers::CustomerKind Common::TownDetail + value: String [0..1] + dateTime: DateTime [0..1] + remark: String [0..1] + reason: String [0..1] residential residentialAndCommercial residentialAndStreetlight residentialStreetlightOthers residentialFarmService commercialIndustrial pumpingLoad windMachine energyServiceSupplier energyServiceScheduler internalUse other + code: String [0..1] + section: String [0..1] + name: String [0..1] + stateOrProvince: String [0..1] + country: String [0..1] «Compound» Common::Priority «Compound» Common::Priority Common::StreetDetail Common::StreetDetail + rank: Integer [0..1] + type: String [0..1] + justification: String [0..1] + number: String [0..1] + name: String [0..1] + suffix: String [0..1] + prefix: String [0..1] + type: String [0..1] + code: String [0..1] + buildingName: String [0..1] + suiteNumber: String [0..1] + addressGeneral: String [0..1] + addressGeneral2: String [0..1] + addressGeneral3: String [0..1] + withinTownLimits: Boolean [0..1] «Enumeration» PaymentMetering: :SupplierKind PaymentMetering: :SupplierKind utility retailer other lse mdma msp «Compound» Assets::AcceptanceTest Assets::AcceptanceTest + type: String [0..1] + success: Boolean [0..1] + dateTime: DateTime [0..1] «Compound» «Enumeration» Metering:: MeterMultiplierKind Common::TelephoneNumber Common::TelephoneNumber Metering:: MeterMultiplierKind «Compound» Assets::LifecycleDate Assets::LifecycleDate + countryCode: String [0..1] + areaCode: String [0..1] + cityCode: String [0..1] + localNumber: String [0..1] + extension: String [0..1] + dialOut: String [0..1] + internationalPrefix: String [0..1] + ituPhone: String [0..1] kH kR kE ctRatio ptRatio transformerRatio + manufacturedDate: Date [0..1] + purchaseDate: Date [0..1] + receivedDate: Date [0..1] + installationDate: Date [0..1] + removalDate: Date [0..1] + retiredDate: Date [0..1] «Compound» «Compound» Common:: ElectronicAddress Common::StreetAddress Common::StreetAddress Common:: ElectronicAddress + streetDetail: StreetDetail [0..1] + townDetail: TownDetail [0..1] + status: Status [0..1] + postalCode: String [0..1] + poBox: String [0..1] + lan: String [0..1] + mac: String [0..1] + email1: String [0..1] + email2: String [0..1] + web: String [0..1] + radio: String [0..1] + userID: String [0..1] + password: String [0..1]

  37. espiderived: UsagePoint current Extends UsagePoint based on newer CIM model: iec61970cim17v06a_iec61968cim 12v10_iec62325cim03v02 Backwards compatibility assured by adding new elements to end of list.

  38. billLastPeriod • billLastPeriod – The total bill for the billing period – billLastPeriod = ∑ costAdditionalDetailLastPeriod.LineItem.amount costAdditionalLastPeriod – Deprecate and if present, should have the same value of billLastPeriod – if you populate the costAdditionalDetailLastPeriod, then costAdditionalLastPeriod would be expected to have the total IntervalReading.cost – Provided if FB_12 is selected and should probably be consistent with costAdditionalDetailLastPeriod.LineItem.amount records for which these costs pertain – but this is not guaranteed billLastPeriod = ∑ costAdditionalDetailLastPeriod.LineItem.amount – Should always add up to billLastPeriod. If the details provided are not complete, a record “other” should be included to make up the difference and indicate that all billing details have not been provided. – If no amounts are presented in this detail, there is no need for a compensating “other” record to add up to billLastPeriod • • •

  39. Query Parameters • There was a significant discussion, led by Partha, about how the “depth” query parameter should work. During the call we accessed the “Implementation Agreement” and discovered the only documentation of the query parameters is a list of the query parameter keywords. The group agreed we need to document how the parameters work and the expected format they should contain. For example, the date query parameters (published-min, published-max, updated-min, and updated-max) need to indicate they are to be UTC “Z” time formats and not epoch time. • As a result of the two above items, additional test need to be added to FB_37 to: – Ensure query elements containing epoch time generate a 400 response – Ensure query elements containing ALL generate a 400 response – Ensure responses match requested max & depth values

  40. Topics • • Value mapping for TOU and CPP and ConsumptionTier sftp for Batch/Bulk/{bulkId} – Is there a “user”? – sftp://user@localhost/DataCustodian/espi/1_1/resource/Batch/Bulk/{bulkId} • Suggestion – fixed user= “GreenButton” so no PII in sftp startup • Alternative – let DC provide arbitrary uuid in the notification • Conclusion: the DC chooses the “user” and includes it in the notificationUri where the TP gets it for use in the exchange. Target Firm Up end of July: Retailcustomer.xsd – Need to define function blocks -- Potentials: • FB_X1 Minimal that only provides actual IDs and UsagePoints • FB_X2 Service Location Contents Name and Addresses and location, • No fb needed now End device • No fb needed now Pricing Structure • FB_X3 Account data for DMD access – Access Tokens • Access tokens to access? Individual with access_token, bulk with client_access_token – URI in Authorization • customerResourceUri needed in OAuth authorization response and Authorization xml structure • customerResourceUri in client access Authorization would be batch/BulkRetailCustomerInfo • Test requirements – – If Scope has RetailCustomer function blocks, then » Verify Authorization has customerResourceUri » Verify Oauth response has customerResourceUri » Verify client_access_token works for esource/Batch/BulkRetailCustomerInfo » Verify access_token works for resource/RetailCustomer… – Additional attributes • Move in move out – use CustomerAgreement.validityInterval • • Target Firm Up List end of July: UsageSummary.CostAdditionalDetail.itemKind – Tax, Other, ThirdParty energy provider fee, ThirdParty energy provider usage, Credit, Discount, Usage, Demand, TOU, incentive, informational, Customer Charge, Energy Charges, Supply Charges, Distribution Charges, Transmission Charges, Generation Charges, State Gross Receipts Tax, State Tax Adjustment, Administrative Charge, Ancillary Charge, Balancing Service Charge, Working Capital Charge, Purchased Generation Adjustment, Cost Adjustment, Service Location Distribution Charge, Other, Minimum charge, Tier Charge, Adjustment Charge, Program Charge/Credit, Amount Paid, Power Factor adjustment, DWR energy credit (calculation and credit value), UUT exemption status, State Tax, Local Tax, Transmission Charges, Distribution Charges, Nuclear Decommissioning Charges, Public Purpose Programs Charges, Franchise Fee, Generation Charge – Will finish consolidation of list and review OAuth login requirements for the testing •

  41. ItemKind Simplified 1 2 3 Energy Generation Fee. A charge for generation of energy. Energy Delivery Fee. A charge for delivery of energy. Energy Usage Fee. A charge for electricity, natural gas, water consumption Administrative Fee. A fee for administrative services. Tax. A local, state, or federal energy tax. Energy Generation Credit. A credit, discount or rebate for generation of energy. Energy Delivery Credit. A credit, discount or rebate for delivery of energy. Administrative Credit. A credit, discount or rebate for administrative services. Payment. A payment for a previous billing. Information. An informational line item. 4 5 6 7 8 9 10

  42. TOU, CPP, ConsumptionTier Code Descriptions • TOU, CPP, ConsumptionTier are integers in ReadingType/IntervalReading • What does “3” mean? • Draft Solution: – Provide an optional table in UsagePoint that provides the code, name, and description of the values of TOU and CPP when used underneath it.

  43. UsagePoint.ProgramMappings <UsagePoint> </UsagePoint> <ServiceCategory> <kind>1</kind> </ServiceCategory> <programIdMappings> <programIdMapping> </programIdMapping> <programIdMapping> </programIdMapping> </programIdMappings> <tOUorCPPorConsumptionTier>tou</tOUorCPPorConsumptionTier> <code>1</code> <name>Summer Peak</name> <tOUorCPPorConsumptionTier>tou</tOUorCPPorConsumptionTier> <code>2</code> <name>Winter Peak</name>

  44. RetailCustomer Architecture • API –GET .../resource/Batch/RetailCustomer/{id} –GET .../resource/CustomerInformation/{id} –… –GET .../resource/CustomerInformation/{id}/RetailCustomer/{id}/CustomerAccount/{id}/CustomerAgreement –GET …/resource/Customer/{id} –GET .../resource/CustomerAgreement/{id} –GET .../resource/Batch/BulkRetailCustomerInfo/{id} PG&E proposal Current Architecture

  45. Large Organization Use Case Corporate Authorizes EMS Co Resource Example EMS Co Web Account Safeway Company Customer SF Regional Mgr, Oakland RM Customer Account Individual Stores Service Agreement Gas service, Electrical service Service Point Usage Points • There is sometimes an authority that can authorize a large number of individual accounts, e.g. gsa/McDonalds, … where the individual accounts may be franchised or otherwise owned/managed – yet the individual accounts have the responsibility to maintain the utility account and pay the bills.

  46. Query Parameters • There was a significant discussion, led by Partha, about how the “depth” query parameter should work. During the call we accessed the “Implementation Agreement” and discovered the only documentation of the query parameters is a list of the query parameter keywords. The group agreed we need to document how the parameters work and the expected format they should contain. For example, the date query parameters (published-min, published-max, updated-min, and updated-max) need to indicate they are to be UTC “Z” time formats and not epoch time. As a result of the two above items, additional test need to be added to FB_37 to: – Ensure query elements containing epoch time generate a 400 response – Ensure query elements containing ALL generate a 400 response – Ensure responses match requested max & depth values Jerry Yip has some additional itemKind elements he wants to discuss during next week’s OpenADE Task Force call, which he will provide in a follow up e-mail. Jerald Pinnecker wants to discuss “subscriptions” during next week’s OpenADE Task Force call. Presently they send subscription data to a Third Party when they register and he wants to know how that data is then tied to the access token when the Third Party completes the authorization request. Additionally, he wants to know who the Third Party is supposed to use the access token. • • •

  47. OAuth Authorization Failure Mode Usage Scenario: 1. TP redirect user to DC scope selection. 2. User approves TP and scope. 3. DC redirects user to TP with scope parameter. 4. TP redirects users to DC's OAuth /authorize endpoint with scope and client_id parameters. 5. DC redirects back to TP redirect_uri with OAuth code parameter. 6. TP makes a request to DC's OAuth /token endpoint with the code. 7. DC responds with an access_token and refresh_token. 8. TP's server crashes and doesn't save either token. • How is the TP supposed to get new tokens? In normal OAuth, you simply redirect the user back to the OAuth /authorize endpoint, the user approves access again and gets redirected back with a new code. • However, at least in one current implementation, the TP has to redirect the user to the scope selection screen, where the user will be told that they have already authorized the TP with no option to re-authorize. In order to get new tokens, the use manually has to cancel authorization, which causes them to get redirected to the main website. Then the user manually has to go back to the scope selection screen and authorize the TP again. • This re-authorization process is not ideal because it requires us training the user to cancel-then-manually-go-back- and-reauthorize, which is a very confusing and complex process and doesn't redirect the user back to the TP after cancellation. • Two possible solutions: – 1. On the DC's scope selection interface, have a re-authorize button if the user has already authorized the TP. – 2. Allow TP's to redirect the user to OAuth's /authorize endpoint with the same scope, and have the DC ask for re-authorization at that point. – Option 1 is better for GBCMD, in my opinion, because it also allows for the scenario where the TP loses the scope parameter, too. Option 2 is the more technically correct OAuth procedure. All other OAuth services I can think of do Option 2, but they also don't require a pre-defined scope parameter for the /authorize endpoint (so there's nothing to lose).

  48. GET Subscription w/wo query parameters – Default required behaviors Problem: The amount of data that is in a: GET /Batch/Subscription/{subscriptionId} can potentially be very large. What is the obligation of a DC when that message is received without query parameters? What about the desire of some DC’s to provide only a fixed size response of say “X” months? What about when a subscription contains 1/10/1000 UsagePoints? • Alternatives – 1) Requires date range in GET /Batch/Subscription/{subscriptionId} • DC responds with 202 if data is too large to return right away – Returns with notification when data is ready and can provide query distinguished URIs – 2) DC decides maximum depth to return when no query parameters • TP may get whole history (from scope parameter HistoryLength) or may get less. – 3) Term in Scope for default GET Subscription depth • The scope can indicate for the specific subscription what the default length is. The DC decides during scope selection what to include in the offered scopes. • Solution: – Publish min/max required on resource/Batch/XXXXX APIs

  49. Discussion of responses to requests for large data sets Given: • • • • • It's possible for a subscription to have small or enormous at data sets There GB CMD applications on the market that don't require query parameters Query parameters are specified and the Min and Max public support required for our minimum set If you have or don't have query parameters the third party is likely always to ask the first time for everything We agreed in a face-to-face that we were going to support a response of 202 when large off-line data sets are requested In a response asking for everything it should be the discretion of the data custodian to determine what the largest response it's willing to give Some data custodians want to define a fixed maximum size for any request An empty response (feed with no resources) implies no more data Therefore: • Query parameters should remain optional in any given request • Absence of query parameters means “everything” – this means all available data that DC is willing to provide • 202 is a valid response for …./Batch/… followed by a notification when data is ready • The DC decides how much a maximum data response to an API request will be • A TP that receives less than anticipated can ask for older data. • If he gets back an empty feed, he has it all. Note: that if there is a gap in the data and he asks for the gap, he may get empty feed but there may be more data behind it. • • •

  50. CIM Tariff Model class TariffProfile class TariffProfile Document Customers:: PricingStructure Customers:: PricingStructure +PricingStructures 0..* +Tariffs 0..* Document Customers:: Tariff IdentifiedObject Metering:: ReadingType Customers:: Tariff Metering:: ReadingType Charges associated with time threshholds Charges associated with value threshholds +Tariffs 0..* +ReadingType 0..1 +TariffProfiles 0..* Document +TariffProfiles +TariffProfiles TariffProfile TariffProfile 0..* 0..* + tariffCycle: String [0..1] +ConsumptionTariffIntervals +TimeTariffIntervals +ConsumptionTariffIntervals 0..* 0..* 0..* TimeTariffInterval TimeTariffInterval ConsumptionTariffInterval ConsumptionTariffInterval +TouTariffIntervals +ConsumptionTariffIntervals + sequenceNumber: Integer [0..1] + startTime: Time [0..1] + sequenceNumber: Integer [0..1] + startValue: Float [0..1] 0..* 0..* 0..* 0..* +TimeTariffIntervals +ConsumptionTariffIntervals «Compound» AccountingUnit IdentifiedObject Charge AccountingUnit Charge +Charges +Charges + value: Float [0..1] + energyUnit: RealEnergy [0..1] + monetaryUnit: Currency [0..1] + multiplier: UnitMultiplier [0..1] + kind: ChargeKind [0..1] + fixedPortion: AccountingUnit [0..1] + variablePortion: PerCent [0..1] 0..* 0..* +ParentCharge 0..1 +ChildCharges 0..*

More Related