OpenSG / NIST Conference Call September 16, 2009

Transcription

1 OpenSG / NIST Conference Call September 16, 2009

2 Agenda 1:00pm 1:10pm - Welcome and Introductions 1:10pm 1:30pm Recommendations on PAP work assignments 1:30pm 2:30pm - Why the CIM should be the basis for Price, Schedule and DR 2:30pm 3:00pm - Discussions and recommendations 3:00pm End meeting 2

3 Recommendations on PAP Work Assignments Coordinate NIST PAPs (PAP03, PAP04 and PAP09) with current OpenSG work plans OpenSG coordination plan Common Semantic Model (IEC 61968/ harmonized with IEC 61850) IEEE and IETF standards for communications MAC/PHYs are sourced from IEEE IEEE and IEEE P1901 are targeted for first generation deployment, however, any MAC/PHY can be used (WiFi, Ethernet, etc.) Networking standards are sourced from IETF Application work is aligned with IEC TC57 and the CIM. Application message exchange is based on XML. Work is happening now in IEEE, IETF, IEC, ZigBee and HomePlug around this plan Observations Regarding Pricing, Scheduling and Demand Response Functionality Much of this functionality is needed across multiple SG systems including OpenHAN, OpenADE, and OpenADR The same type of data should be called the same thing and have identical meaning across all data exchanges (XML) required to satisfy use cases This functionality already exists in the current CIM (IEC 61968) SG Systems services are based on IEC (AMI), which includes uses all of these functions There needs to be a central organization to align business and utility requirements OpenSG is already doing this and will provide proposed solutions to the SDOs IEC TC57 for business functional requirements being met through the CIM and various forms of derived XML Would ideally collaborate with OASIS and other parties as necessary to leverage their knowledge and expertise 3

4 The CIM is the Basis for a Common Systems Language for Utilities The same dictionary is used for multiple forms of human communication: Letters Phone calls Conversations s Etc. In similar manner, the same CIM is used for multiple forms of computer communication: XML RDF OWL DDL Etc. One Dictionary Supports Many Forms of Communication 4

5 Recommendations on PAP Work Assignments Use IEC TC57 CIM as the basis for Price, Schedule and DR Interface standards should be based on Common Semantics (e.g., CIM) to avoid adding to Integration Anarchy The CIM supports many communication paradigms: XML, ASN.1, OWL, DDL, etc. About the Common Information Model (CIM) A static data model developed and maintained by IEC TC57 A Unified Modeling Language (UML) based information model representing real-world objects and information entities exchanged within the electric power industry Has been developed in IBM s Rational Rose modeling tool, but is now being maintained in Enterprise Architect Purpose is to enable integration of applications/systems It is a common model behind all messages exchanged between systems So that there is a common language to navigate and access complex data structures in any database Inspiration for logical data schemas Not tied to a particular application s view of the world Communication methods using the CIM vocabulary XML is a common data expression syntax Binary XML (such as W3C EXI, Fast Infoset, etc.) can be used as a compact representation for device message exchange Work has started with IETF on an embedded web services transport protocol definition for exchange of binary XML 5

6 For PAP 03, Pricing: Key Points for Consideration Electricity prices, both wholesale and retail, are set by Regional Transmission Organizations (RTOs) and state public utility commissions. Significant variation exists in how each of the RTOs operates relative to demand resources Consumer cost of electricity is governed by tariff by state utility regulatory commissions, or price structure determined by an ESP/REP in a deregulated retail market. Retail electricity prices are set, to a large extent, by state regulators and result from utility rate case filings. Settled Price on the wholesale market is not the same as the tariff or retail price a consumer would pay. There may be some shared attributes between the bid/settlement at the wholesale level and the tariff/pricing at the retail level, but they are fundamentally different concepts. Takeaway: Objectives and Expected Outcomes from PAP03 are not clearly defined 6

7 Proposed changes for PAP03: Common Pricing Model Task Responsible Proposed Responsible Reason for proposed change Proposed plan to achieve Convene Cross-Domain Group Price+ OASIS, NAESB OASIS, NAESB, OpenSG Need to develop a single requirements document around this PAP. Need to consider price model planned for Smart Energy Profile.2.0 The FIX protocol does not seem appropriate for premise devices. Meet to discuss OpenSG current work in partnership with NAESB with regard to system requirements. Including, plans to use the CIM for pricing models and to align with current utility pricing models. Discuss extensions and collaboration on future CIM extensions and protocol additions like FIX and WS-Calendar High level concept of operation BAE (volunteer) Survey existing price communication FIX, NAESB FIX, NAESB, OpenSG Need to add OpenSG to this work to capture existing work and current utility deployments Adding responsibility by OpenSG provides a background for work deployed by utilities Data model OASIS, IEC TC57 CIM WG IEC TC57, OpenSG, CIM User s Group It was not clear what the role for OASIS was in terms of the data model Allow IETC TC57 to manage the data model, OpenSG to accelerate process 7

8 Proposed changes for PAP03: Common Pricing Model (Continued) Task Responsible Proposed Responsible Reason for proposed change Proposed plan to achieve Draft pricing specification OASIS IEC TC57, ZigBee, OpenSG (requirements) The pricing models currently used in utility operations are harmonized with the Common Information Model (CIM). This work aligns with utility pricing models in existence today and can be extended for future price model requirements The pricing model should be specified using the IEC TC57 CIM and deployed using XML and binary XML. Vendor consortiums such as OASIS and FIX can use this model to provide higher layer protocol extensions such as FIX Convene Schedule Group CalConnect IEC TC57, ZigBee, OpenSG The CIM contains scheduling features and is aligned with utility operations today. The scheduling model should be specified using the IEC TC57 CIM and deployed using XML and binary XML. IEC TC57 and ZigBee can work with CalConnect and others to provide mappings to WS-Calendar., OpenSG to accelerate process 8

9 For PAP 04, Scheduling: Key Points for Consideration IEC TC 57 CIM should be the basis for scheduling. Common language (XML and binary XML) is then used to allow conveyance of schedule to very simple premise equipment. WS-Calendar can build on the CIM to deploy a calendaring function for enterprise systems and any other class of device that can provide support Takeaway: Allow IEC TC 57, OpenSG (requirements generation) and ZigBee to take the lead and work with OASIS on deployment using WS-Calendar 9

10 Proposed changes for PAP04: Common Scheduling Mechanism Task Responsible Proposed Responsible Reason for proposed change Proposed plan to achieve WS-Calendar Specification ready for review: OASIS IEC TC57, ZigBee The IEC TC57 CIM offers a simpler solution for scheduling more aligned for premise equipment deployment. Align the scheduling feature with the IEC TC57 CIM rather than introduce a new protocol that does not have a history in premise equipment. Work with OASIS on scheduling deployment aligned with the CIM. WS-Calendar Semantic Review completed (ISO 20022, obix) OASIS IEC TC 57, ZigBee, OpenSG ZigBee SE V2 evaluated obix and W3C EXI and concluded EXI was a more efficient XML encoding for premise equipment. Align the scheduling feature with the IEC TC57 CIM, Establish a baseline (binary XML) for use with very simple devices. Work with OASIS on scheduling aligned with the CIM. OpenSG to accelerate process WS-Calendar Incorporated into EMIX: OASIS

11 For PAP 09, DR Signals: Key Points for Consideration IEC TC 57 CIM should be the basis for DR signals. Common language (XML and binary XML) is then used to allow conveyance of DR signals. Message semantics for DR and DER expressed as XML and binary XML. Align with OASIS, CalConnect and FIX for calendaring and price message semantics, based on the CIM. Takeaway: Allow IEC TC 57, OpenSG (requirements generation) and ZigBee to take the lead and work with OASIS, CalConnect and FIX. 11

12 Proposed changes for PAP09: DR Signals Task Responsible Proposed Responsible Reason for proposed change Define proper DER interaction, scope Proposed plan to achieve Collect, analyze and analyze usecases and deliver UML UCAIUG, NAESB Same Message semantics work DR OASIS EITC IEC TC57, OpenSG SG Systems, ZigBee ZigBee Smart Energy Profile (SEP) has already developed DR signals and is harmonizing those with IEC TC57 Work is already in progress between OpenSG SG Systems, ZigBee to align to the CIM Message Semantics work DER OASIS EITC IEC TC57, OpenSG SG Systems, ZigBee Work has begun in ZigBee to use the CIM and work with the DER vendor community to incorporate their use cases. Work has already started with the DER vendor community to align with the CIM. Message Semantics Calendar, Price OASIS EITC IEC TC57, OpenSG SG Systems, ZigBee As noted for PAP03 and PAP04, the message semantics for FIX and WS-Calendar should be changed to align with the CIM. Work is already in progress between OpenSG and ZigBee to deploy messaging, price and calendar via the CIM. 12

13 Proposed changes for PAP05: Standard Meter Data Profiles Task Responsible Proposed Responsible Reason for proposed change Proposed plan to achieve :Produce descriptions and example messaging scenarios to illustrate how meters can be read by simple clients to obtain commonly requested information. None Identified OpenSG AMI-Network, ZigBee OpenSG AMI-Network is listed as one of the SDO leads without an assigned Task Description. The work item on simple clients seems to have been overlooked Add a work items for OpenSG AMI-Network and ZigBee to solve the problem of reading meters from simple devices. 13

14 Proposed changes for PAP07: Electric Storage Interconnection Guidelines Task Responsible Proposed Responsible Reason for proposed change Proposed plan to achieve Task 4: Continue development of object model standards for distributed energy resources (e.g., IEC TC57 WG17 to enhance IEC and IEC TC57 WG14 to develop DER models in IEC CIM), including object models for managing generic storage/generation systems. In addition, these abstract object models will require mapping to the ZigBee Smart Energy Profile (SEP), to Web Services, and potentially to other standard protocols as appropriate for different configurations, environments, and migration from legacy systems. IEEE Energy Storage Subcommittee in P2030, TF1 Alex Takahashi IEEE Distribution Automation WG Georges Simard IEEE Bob Saint NEMA Energy Storage Council (Aug 11 meeting) Ben Biroschak, Brad Roberts EPRI Smart Grid Demo Initiative Matt Wakefield, Dan Rastler Electricity Storage Association Rahul Walawalker, Ali Nourai, Brad Roberts ISO/RTO Council Ken Huber Technology Representative (Power Conditioning System (PCS) and inverter vendor community) Leo Casey, Le Tang DOE Dick DeBlasio, Imre Gyuk, Dan Ton (SEGIS/ES), John Boyes (Sandia), NETL DOE Office of Vehicle Technologies Sue Rogers SAE George Bellino Same list and propose to add OpenSG AMI- Network (Matt Gilmore) and ZigBee for control/monitoring ZigBee is called out in the task but no one was assigned from that group to any of the tasks Include ZigBee as part of the team (with IEEE P2030). 14

15 SG-Systems WG Chair: Brent Hodges Co Chair: Greg Robinson SG-Systems Making Progress on Requirements & Ready/Able to Help SDOs with gap resolutions Requirements are progressing AMI-Ent TF Chair: Wayne Longcore Co-Chair: Greg Robinson OpenADE TF Chair: Dave Mollerstuen Co-Chair: Steve Van Ausdall OpenADR TF Chair: Albert Chiu Co-Chair: Ed Koch OpenHAN TF Chair: Erich Gunther Co-Chair: Use Case Team Chair: Ralph Martinez Co-Chair: Kay Stefferud underway underway SRS Team Chair: Joe Zhou Co-Chair: underway underway Service Definitions Team Chair: Jerry Gray Co-Chair: Shawn Hu planning Awaiting Resoltion of NIST PAP 09 SE 2.0 Interoperability Testing Team Chair: Randy Lowe Co-Chair: Xiaofeng Wang planning planning Awaiting Resoltion of NIST PAP 09 SE 2.0 Security Team Chair: TBD From SG-Security Co-Chair: TBD From SG-Security underway planning Awaiting Resoltion of NIST PAP 09 SE 2.0 Able to propose ways to fill gaps 15

16 Appendix 16

17 How We Derive Message Schemas from the CIM CIM Conforms to CIM Restricts/Narrows CIM Conforms to Profile Profile Concrete Message Conforms to Message Assembly Is assembled as Message Conforms to Syntax Is mapped to XML Schema 17

18 OpenSG Subcommittee Organization Open Smart Grid (OpenSG) Subcommittee SG Security (UtiliSec) Working Group SG Communications (UtiliComm) Working Group SG Systems Working Group SG Conformance (CWG) Working Group (Proposed) AMI-Security AMI-Network OpenHAN Task Force Task Force Task Force Network Interop Task Force OpenADE Task Force OpenADR Task Force Open AMI-ENT Task Force UtilityAMI Interest Group 18

19 Key Collaboration Concept for the SG-Systems Working Group Standard building blocks are defined by IEC working groups (and affiliated CIMug) along with other relevant industry groups e.g., Open Applications Group (OAG), MultiSpeak, OGC Requirements (use cases) are gathered from helpful sources Utilities Industry initiatives The SG-Systems WG articulates Common industry practices that satisfy requirements through the use of standard building blocks. Recommended extensions and changes to standard building blocks are provided back to appropriate standards bodies. 19

20 SG-Systems WG Process Overview - A Well Oiled Machine Use Cases From SCE and others HomePlug & ZigBee SE 2.0 IEC TC57 WG14, OASIS, IEEE Other SDOs NIST EPRI, MultiSpeak System Requirements (SRS) Team Recommendations to IEC TC57 WG14: Proposed CIM Extensions Message Schemas Updates Requirements Updates Recommendations to other SDOs Task Forces Use Case Team Service Definitions Team Interoperability Testing Team Business-Oriented, Common Format Use Cases Based on SRS Reference Model Integration Requirements Patterns Sequence Diagram Services WSDL 20

21 SG-Systems Organization Structure SG-Systems WG Chair: Brent Hodges Co Chair: Greg Robinson AMI-Ent TF Chair: Wayne Longcore Co-Chair: Greg Robinson OpenADE TF Chair: Dave Mollerstuen Co-Chair: Steve Van Ausdall OpenADR TF Chair: Albert Chiu Co-Chair: Ed Koch OpenHAN TF Chair: Erich Gunther Co-Chair: Use Case Team Chair: Ralph Martinez Co-Chair: Kay Stefferud underway underway SRS Team Chair: Joe Zhou Co-Chair: underway underway Service Definitions Team Chair: Jerry Gray Co-Chair: Shawn Hu planning? SE 2.0 Interoperability Testing Team Chair: Randy Lowe Co-Chair: Xiaofeng Wang planning planning? SE 2.0 Security Team Chair: TBD From SG-Security Co-Chair: TBD From SG-Security underway planning? SE

22 22

23 An Open AMI from SG Systems s SRS Customer Info. & Billing Distribution HAN Outage Revenue Protection AMI Service Manager Enterprise Bus + Common Model & Service AMI-ENT Customer Portal Third Party Portal Meter Data Demand Response Meter Asset AMI Network Asset Representative of AMI-ENT components, not all inclusive. 23

24 SG Systems Reference Model AMI Head End #1 Customer Presentment & Analysis (C&I) Third Party Portal Customer Presentment & Analysis (Residential) Customer Portal AMI Meter Asset M aintenance C&I Demand Resource AMI Network Asset Maintenance Demand Response AMI Head End #2 AMI I Customer Facing Components Home Area Network Meter Data AMI Head End #n Demand Response Command & Control AMI Service Manager P rocess Orchestration Metadata Repository Data Warehouse & Data Mart Process Integration Platform Complex Event Processing Federated ESBs + ESM S ervice EII/EDI/ETL + ESM Real Time BI Monitoring & Security Reporting & Analysis Information Platform Customer Information Distribution Enterprise Asset Revenue Protection AMI Specific Components Customer Relationship Distribution SCADA Energy AMI Network Customer Information Analysis Distribution Engineering Analysis Geographic Information Outage Work and Mobile Power Trading AMI Edge Components Distribution Operational Analysis Meter Data Analysis Utility Operations and Enterprise Analysis Components Supply Chain Transformer Load Utility Operations and Enterprise Components 24

25 Use Case Driven

26 CIM-Based Service Identification

27 Inventory of 142 CIM-Based Services Supporting Use Cases for AMI-Enterprise (Refer to Use Case & Scenario Integration Requirement Functional Description of the Service B1-S1 REQ-B1004 MDUS receives the meter reading results on B1-S12 REQ-B1011 MDUS receives meter reads B1-S15 REQ-B1012 MDUS notifies meters with reading problems Operation Pattern Service Name Service Operation Service Consumer (Outbound) Service Provider (Inbound - WS) Information Object (normalized) Created MeterReading CreatedMeterReading Head End MDUS MeterReading Created MeterReading CreatedMeterReading Field Tool MDUS MeterReading Created MeterSystemEvent CreatedMeterSystemEvent MDUS? MDUS MeterSystemEvent B1-S15 REQ-B1013 AMI Head End operator receives meter service orders Created MeterServiceOrder CreatedMeterServiceOrder MDUS Head End MeterServiceOrder B1-S17 REQ-B1014 Request billing determinant Create BillingDeterminantRequest CreateBillingDeterminant CIS MDUS BillingDeterminant B1-S17 REQ-B1014 Request billing determinant Created BillingDeterminant CreatedBillingDeterminant MDUS CIS BillingDeterminant B1-S2 REQ-B1001 Head End receives the Create MeterReading CreateMeterReading TBD Head End MeterReading request for a meter reading B1-S2 REQ-B1002 MDUS receives a meter Created MeterReading CreatedMeterReading Head End MDUS MeterReading reading on demand B1-S2 REQ-B1003 A user or system receives Created MeterReading CreatedMeterReading MDUS TBD MeterReading a meter reading on demand B1-S3 REQ-B1006 CIS receives meter event Created MeterSystemEvent CreatedMeterSystemEvent Head End/MDUS CIS MeterSystemEvent B1-S7 REQ-B1009 MDUS receives the request for meter readings B1-S7 REQ-B1010 Third party receives the meter readings B1-S8 REQ-B1009 MDUS receives the request for meter readings B1-S8 REQ-B1010 Third party receives the meter readings B2-S1 REQ-B2001 Send scheduled shut off notification B2-S1 REQ-B2002 Send scheduled shut off command B2-S1 REQ-B2003 Send scheduled shut off command confirmation Create MeterReading CreateMeterReading Third Party Portal MDUS MeterReading Created MeterReading CreatedMeterReading MDUS Third Party Portal MeterReading Create MeterReading CreateMeterReading Third Party Portal MDUS MeterReading Created MeterReading CreatedMeterReading MDUS Third Party Portal MeterReading Created ScheduledEvent CreatedScheduledEvent CIS Head End ScheduledEvent Created ConnectDisconnect CreatedConnectDisconnect CIS Head End ConnectDisconnect Created CommonConfirmation CreatedCommonConfirmation Head End CIS CommonConfirmation B2-S1 REQ-B2004 Send meter read (final) Created MeterReading CreatedMeterReading Head End MDUS MeterReading B2-S2 REQ-B2005 Request AMI Meter status Create MeterStatusRequest CreateMeterStatus CIS Head End MeterStatus

28 OpenHAN - Home Area Network

29 OpenHAN OpenHAN SRS 1.04 ratified March 2008 SRS used by ZigBee and HomePlug technology alliances as basis for SE 2.0 Market Requirements Document (MRD) OpenHAN to update SRS based on SE 2.0 MRD and market developments OpenHAN to review SE 2.0 artifacts as provided to facilitate NIST open review process: Technical Requirements Document Proposed CIM Extensions Proposed Service Definitions

30 OpenADE - Automated Data Exchange Third Parties Energy Usage Energy AMI AMI & Internet Utilities Consumers Energy Delivery and The Changing Dynamics of Energy Services

31 OpenADE Permits utilities to share, at the consumer s request and under the consumer s direction, a broad set of that consumer s utility data with specific 3 rd Parties. Immediate Scope (i.e. OpenADE 1.0) includes usage data from utility back end Broader Vision (requirements due post-01/2010) includes pricing, network events, premises configuration, HAN-related data, etc.

32 OpenADE Timeline / Status 04/09: Automated Data Exchange group commissioned at OpenSG quarterly meeting 05/09: Begin weekly meetings to gather business requirements / use cases / user requirements 08/09: Initiate SRS, Services work (in parallel w/ requirements gathering) 10/09: Ratify initial Requirements collection (v1.0) 12/09: Preliminary SRS, Services definitions (v0.1) 01/10: Ratify initial SRS, Services definitions (v1.0) 01/10: Follow on Requirements collection, to include additional elements identified at NIST Smart Grid Workshop

33 OpenADR Automated Demand Response Direct Load Control, (not OpenADR Messages) Utility/ISO OpenADR Message Third Party Service Provider Facility

34 OpenADR Focused on requirements and specifically on deliverables for NIST PAP 09. Currently engaged with horizontal Use Case and SRS teams within OpenSG. In discussions with NAESB and OpenHAN on collaboration on NIST PAP 09 deliverables. Next steps: Analyze existing work product from Use Case and SRS teams to recommend changes and extensions. Become more closely engaged with NAESB on collaboration and participate in joint taskforce.