“SG-Systems” (Smart Grid – Operational Applications Integration) Charter & Status Brent Hodges, Chair, SG-Systems Greg Robinson, Co-Chair, SG-Systems.
Download ReportTranscript “SG-Systems” (Smart Grid – Operational Applications Integration) Charter & Status Brent Hodges, Chair, SG-Systems Greg Robinson, Co-Chair, SG-Systems.
“SG-Systems” (Smart Grid – Operational Applications Integration) Charter & Status Brent Hodges, Chair, SG-Systems Greg Robinson, Co-Chair, SG-Systems OpenSG Subcommittee Organization Open Smart Grid (OpenSG) Subcommittee SG Security (UtiliSec) SG Communications (UtiliComm) Working Group Working Group SG Systems Working Group 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 SG Conformance (CWG) Working Group (Proposed) NIST Conceptual Model Focus Of SG-Systems [Source: NIST Interim Roadmap] Business Drivers Interoperability requires many standards in a profile stack Work with relevant SDOs per layer of profile stack (e.g., information standards, security standards, transport standards, media standards, etc.) to ensure complete solutions for inscope interfaces. Need formal industry standards, but the SDO process is relatively slow & needs more user input Work collaboratively with SDOs to ensure common user requirements are appropriately addressed Facilitate standards development by proposing potential solutions for addressing gaps in existing standards. For Information Standards, resolve (don’t add to) semantic chaos Avoid having the same information defined with different names, varying definitions, etc. Ensure same information standards can be used across different communication profiles While mapping to other standards will be unavoidable, strive to use, correct and extend one information model standard: The SDO ultimately determines when and how its standards are updated based on input. The IEC TC57 Common Information Model (CIM) is the default information model for this purpose. There is substantial information overlap among AMI, ADE, HAN and ADR While requirements and services vary significantly, they can be built using the same information model. To ensure consistency of information across all domains, SG-Systems WG is assigned the task of defining requirements and proposing solutions to gaps in existing standards. SG-Systems WG Scope SG-Systems WG: The SG-Systems Working Group defines requirements, policies, and services, based on utility industry standards such as the Common Information Model (CIM), required for information exchange from and to utility enterprise back office systems and between these back office systems and data acquisition and control servers (e.g., MDMS, AMI Head Ends, SCADA, etc.). Task forces are established on an as needed basis to accomplish these goals for specific functional areas. In addition to work performed by their ‘vertical team,’ Task Force Chairs act as matrix managers to ensure their functional requirements are met through the ‘horizontal teams’ supporting them. ‘Horizontal Teams’ are ongoing, providing consistent artifacts for each increment of functionality that is requested of them by the functional (vertical) teams. 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 Task Forces System Requirements (SRS) Team Use Case Team Business-Oriented, Common Format Use Cases Based on SRS Reference Model Service Definitions Team Recommendations to IEC TC57 WG14: •Proposed CIM Extensions •Message Schemas Updates •Requirements Updates Recommendations to other SDOs Interoperability Testing Team •Integration Requirements •Patterns •Sequence Diagram •Services •WSDL SG-Systems Organization Structure SG-Systems WG Chair: Brent Hodges Co Chair: Greg Robinson AMI-Ent TF OpenADE TF OpenADR TF OpenHAN TF Chair: Wayne Longcore Co-Chair: Greg Robinson Chair: Dave Mollerstuen Co-Chair: Steve Van Ausdall Chair: Albert Chiu Co-Chair: Ed Koch Chair: Erich Gunther Co-Chair: Underway Underway With NAESB Underway Underway With NAESB Use Case Team Chair: Ralph Martinez Co-Chair: Kay Stefferud SRS Team Chair: Joe Zhou Planning Collaboration With SE 2.0 & OASIS Collaboration With SE 2.0 Planning Planning Collaboration With SE 2.0 & OASIS Collaboration With SE 2.0 Underway Underway Collaboration With SE 2.0 & OASIS Collaboration With SE 2.0 Service Definitions Team Chair: Jerry Gray Co-Chair: Shawn Hu Interoperability Testing Team Chair: Randy Lowe Co-Chair: Xiaofeng Wang Security Team Chair: Darren Highfill Key Collaboration Concept for the SG-Systems Working Group Standard building blocks are defined by CIMug and the affiliated IEC working groups along with other relevant industry groups Requirements (use cases) are gathered from helpful sources e.g., Open Applications Group (OAG), MultiSpeak, OGC Utilities Industry initiatives The SG-Systems WG articulates Industry Best Practices (see next slide) 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. Our Focus: Finding/Developing Best Practices & Making Them into Vetted “Industry Best Practices” Utility’s Projects - Design & Local Utility Projects Implementations --------------- Utility’s Architecture ----------------------Industry Best Practices Interoperability Testing --------------------------------- Industry Best Practices -----------------------------------------Standards Conformance & Interoperability Testing Consortiums & User Groups like OpenSG (business requirements) & CIMug (optimization & implementation support) Standards Development Organizations (SDOs) like IEC TC57 Working Group 14 for the IEC 61968 series of standards •The scope of AMI-ENT is the systems and/or applications within and around the utility enterprise and the inter-systems related business functions and stops at the boundaries of applications and the edge of utility enterprise. •The focus is on how these systems are to be integrated and composed to support AMI related business processes and functions. •Edge applications are those applications that communicate with networks and devices in the field, as well as those that communicate with other businesses or enterprises (generally defined as third parties). An Open AMI from AMI-Ent’s SRS Customer Info. & Billing Outage Management Distribution Management Revenue Protection HAN Management AMI Service Manager Enterprise Bus + Common Model & Service AMIAMI-ENT Demand Response Management Customer Portal Third Party Portal Meter Data Management Representative of AMI-ENT components, not all inclusive. Meter Asset Management AMI Network Asset Management AMI-Ent Reference Model Customer Presentment & Analysis (C&I) Customer Presentment & Analysis (Residential) AMI Meter Asset Maintenance AMI Network Asset Maintenance Third Party Portal Customer Portal C&I Demand Resource Management Demand Response Management Home Area Network Management Meter Data Management AMI Head End #1 AMI Head End #2 AMI Customer Facing Components Revenue Protection Process Integration Platform AMI Head End #n Process Orchestration Complex Event Processing Monitoring & Management AMI Specific Components Federated ESBs + ESM Demand Response Command & Control Metadata Repository Service Management Security Management EII/EDI/ETL + ESM AMI Service Manager AMI Network Management AMI Edge Components Data Warehouse & Data Mart Real Time BI Customer Information Management Customer Relationship Management Distribution Management Distribution SCADA Enterprise Asset Management Energy Management Geographic Information Management Work and Mobile Management Outage Management Power Trading Supply Chain Management Transformer Load Management Reporting & Analysis Information Management Platform Customer Information Analysis Distribution Engineering Analysis Distribution Operational Analysis Meter Data Analysis Utility Operations and Enterprise Analysis Components Utility Operations and Enterprise Components Use Case Driven CIM-Based Service Identification Inventory of 142 CIM-Based Services Supporting Use Cases for AMI-Enterprise (Refer to http://www.smartgridipedia.org/index.php/AMI_Enterprise) Use Case & Integration Scenario Requirement Functional Description of Operation the Service Pattern Service Name Service Operation Service Provider Information Object (Inbound - WS) (normalized) CreatedMeterReading Service Consumer (Outbound) Head End B1-S1 REQ-B1004 MeterReading B1-S12 REQ-B1011 B1-S15 REQ-B1012 MDUS receives the meter Created reading results on scheduled basis.meter MDUS receives Created reads MDUS notifies meters with Created reading problems MDUS MeterReading MeterReading CreatedMeterReading Field Tool MDUS MeterReading MeterSystemEvent CreatedMeterSystemEvent MDUS? MDUS MeterSystemEvent B1-S15 REQ-B1013 MeterServiceOrder CreatedMeterServiceOrder MDUS Head End MeterServiceOrder REQ-B1014 AMI Head End operator Created receives meter service orders Request billing determinant Create B1-S17 BillingDeterminantRequest CreateBillingDeterminant CIS MDUS BillingDeterminant B1-S17 REQ-B1014 Request billing determinant Created BillingDeterminant CreatedBillingDeterminant MDUS CIS BillingDeterminant B1-S2 REQ-B1001 MeterReading CreateMeterReading TBD Head End MeterReading B1-S2 REQ-B1002 Head End receives the Create request for a meter reading on demand MDUS receives a meter Created reading on demand MeterReading CreatedMeterReading Head End MDUS MeterReading B1-S2 REQ-B1003 Created MeterReading CreatedMeterReading MDUS TBD MeterReading B1-S3 REQ-B1006 A user or system receives a meter reading on demand CIS receives meter event Created MeterSystemEvent CreatedMeterSystemEvent CIS MeterSystemEvent B1-S7 REQ-B1009 MDUS receives the request Create for meter readings MeterReading CreateMeterReading Head End/MDUS Third Party Portal MDUS MeterReading B1-S7 REQ-B1010 Third party receives the meter readings MeterReading CreatedMeterReading MDUS Third Party Portal MeterReading B1-S8 REQ-B1009 MDUS receives the request Create for meter readings MeterReading CreateMeterReading Third Party Portal MDUS B1-S8 REQ-B1010 Third party receives the meter readings Created MeterReading CreatedMeterReading MDUS Third Party Portal MeterReading B2-S1 REQ-B2001 Created ScheduledEvent CreatedScheduledEvent CIS Head End ScheduledEvent B2-S1 REQ-B2002 Created ConnectDisconnect CreatedConnectDisconnect CIS Head End ConnectDisconnect B2-S1 REQ-B2003 Send scheduled shut off notification Send scheduled shut off command Send scheduled shut off command confirmation 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 Created MeterReading OpenHAN - Home Area Network s tion lica p Ap Ot h Ga er Pr (In tewa emis ter e ne y t) Ce rtif ied DG Ce tive rtif ied rac e t n Hy Plu I y bri g-In lit i t d Ad rU e v m an u ce ns dI Co HD Lo ad Co ntr ol PC T n atio nic u m om d C nel e r cu han C Se lity i t U R No eve n-e nu lec e G tric ra Me de Re ter ve Ele nu e ctr ic M Gra ete de r Uti lity AM Ow I G ne atew da nd ay Op era ted AM IB ac kh au lN etw ork ns atio c i l p Ap lity Uti P Ce Uti rem rtifie lity ise d A E Ga pplic MS tew ati ay on (e. HA g., Se Cont t T rol op ler Bo x) Sm art Ap plia nc e Lig htin gC on tro l Ho me Se cu rity t as dc gnal) a o i Br e s blic ric Pu .g,., p y e lit Uti nel ( an h C Ho me Ca Healt h re r me nsu Co s tion lica p Ap 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 OpenADE - Automated Data Exchange Third Parties Energy Usage Energy Management AMI AMI&& Internet Internet Utilities Consumers Energy Delivery and Management The Changing Dynamics of Energy Services 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 3rd Parties. Immediate Scope (i.e. OpenADE 1.0) includes usage data from utility back end Broader Vision (requirements due post-01/2009) includes pricing, network events, premises configuration, HAN-related data, etc. 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 OpenADE Participants Utilities 3rd Parties Consumer Consumers Energy Tendril Networks Citizens Utility Board Florida Power and Light Google UCAN Oncor Greenbox Pacific Gas and Electric Comverge Reliant Juice Technologies Southern California Edison San Diego Gas & Electric Xtensible Solutions (consultants) OpenADR – Automated Demand Response OpenADR Message OpenADR Message LOAD Utility/ISO EMCS Utility/ISO Facility Facility Direct Load Control, (not OpenADR Messages) Facility Proprietary Communications OpenADR Message LOADS OpenADR Message Facility Utility/ISO Utility/ISO Intermediary Facility Third Party Service Provider OpenADR Focused on requirements and specifically on deliverables for NIST PAP 09. Currently engaged with horizontal Use Case and SRS teams within UCA. 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. Remarks on Working Closely With SDO In recent NIST discussions, there is general agreement that formal standards are needed. While IEC is viewed as necessary, it suffers from two major criticisms: The IEC process is too slow There is not enough user participation in IEC standards development IEC TC57 helped form the UCAIug. OpenSG is a user-driven organization that functions as part of the UCAIug OpenSG is able to work with the IEC to resolve these two criticisms: OpenSG ballots its work products and make them publically available as an “Industry Best Practice” OpenSG work products are intended to become a common best practice based on applicable industry standards. Please note that these are NOT standards as OpenSG is not a standards development organization (SDO). Extensions to standards that were needed to meet OpenSG’s business requirements will be provided to the appropriate SDO (e.g., IEC TC57 WG14). The OpenSG hopes that the SDOs will accept its recommended extensions (and the extension will become part of the next release of the standard(s) In the meantime, the user community has something to leverage that is far better than custom extensions performed differently at each individual utility.