120 likes | 203 Vues
“SG-Systems” (Smart Grid – Operational Applications Integration) “Boot Camp” Overview. Brent Hodges, Chair, SG-Systems. Greg Robinson, Co-Chair, SG-Systems. Agenda. 3:00 Brief Overview of SG-Systems (Brent) 3:10 NIST and NAESB Impact/Collaboration With SG-Systems (Brent)
E N D
“SG-Systems”(Smart Grid – Operational Applications Integration)“Boot Camp” Overview Brent Hodges, Chair, SG-Systems Greg Robinson, Co-Chair, SG-Systems
Agenda • 3:00 Brief Overview of SG-Systems (Brent) • 3:10 NIST and NAESB Impact/Collaboration With SG-Systems (Brent) • 3:20 Use Case Process with TOGAF AMI-Ent example (Kay) • 3:35 System Requirements Overview with AMI-Ent example (Joe) • 3:50 Service Definitions Process with AMI-Ent example (Jerry) • 4:05 OpenADE (Steve) • 4:20 OpenADR (Ed or Albert) • 4:35 OpenHAN (Erich) • 4:50 General discussion, questions & answers • 5:00 Adjourn
NIST Conceptual Model [Source: NIST Interim Roadmap]
Business Drivers for SG Systems WG • Interoperability requires many standards in a profile stack • The SDO process is relatively slow & needs more user input • Work collaboratively with SDOs to ensure common user requirements are addressed • Facilitate standards development by proposing potential solutions for addressing gaps in existing standards. • The SDO ultimately determines when and how its standards are updated based on input. • 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 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.
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 Emails 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 6 Proprietary and Confidential
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 Scope
SG-Systems Organization Structure Underway With NAESB Underway Underway With NAESB Underway Collaboration With SE 2.0 & OASIS Collaboration With SE 2.0 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
NIST EPRI, MultiSpeak SG-Systems WG Process Overview HomePlug & ZigBee SE 2.0 IEC TC57 WG14, OASIS, IEEE Other SDOs Use Cases From SCE and others Task Forces Business-Oriented, Common Format Use Cases Based on SRS Reference Model System Requirements (SRS) Team Use Case Team SG-Security WG Service Definitions Team • Integration Requirements • Patterns • Sequence Diagram • Services • WSDL • Recommendations to IEC TC57 WG14: • Proposed CIM Extensions • Message Schemas Updates • Requirements Updates • Recommendations to other SDOs SG-Conformity Working Group
Key Collaboration Concept for the SG-Systems Working Group Standard building blocks are defined by IEC, other Standards Development Organizations, and industry groups: e.g., OAISIS, Open Applications Group (OAG), MultiSpeak, OGC Requirements (use cases) are gathered from helpful sources 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. SG-Systems WG February 2010
Utility’s Projects - Design & Implementations --------------- Utility’s Architecture ----------------------- Industry Best Practices Interoperability Testing --------------------------------- Industry Best Practices ------------------------------------------ Standards Conformance & Interoperability Testing ----------------------------------------------------- Industry Standards Our Focus: Finding/Developing Best Practices & Making Them into Vetted “Industry Best Practices” • Local Utility Projects • 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 SG-Systems WG
Remarks on Working Closely With SDO • 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” • Please note that these are NOT standards as OpenSG is not a standards development organization (SDO). • OpenSG work products are intended to become a common best practice based on applicable industry standards. • 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.