“SG-Systems” (Smart Grid – Operational Applications Integration) “Boot Camp” Overview Brent Hodges, Chair, SG-Systems Greg Robinson, Co-Chair, SG-Systems.
Download ReportTranscript “SG-Systems” (Smart Grid – Operational Applications Integration) “Boot Camp” Overview Brent Hodges, Chair, SG-Systems Greg Robinson, Co-Chair, SG-Systems.
“SG-Systems”
(Smart Grid – Operational Applications Integration)
“Boot Camp” Overview
Brent Hodges, Chair, SG-Systems Greg Robinson, Co-Chair, SG-Systems
Agenda
Introductions and Brief Overview of SG-Systems Requirements Gathering – Use Cases and System Requirements Overview with AMI-Ent example OpenADE OpenADR OpenHAN EIM Task Force General discussion, questions & answers Adjourn
Open Smart Grid (OpenSG)
Technical Committee
SG Communications
Working Group
SG Conformity
Working Group
SG Network
Task Force
Network Interop
Task Force
Edge Conformance Enterprise Conformance Security Conformance
SG Security
Working Group
AMI-Security
Task Force
CyberSec-Interop
Task Force
Usability Analysis
Task Force
SG Simulations Working Group Observers
EEI, UTC
SG Systems
Working Group
AMI-Enterprise
Task Force
Enterprise Info Mgmt
Task Force
OpenADE
Task Force
OpenADR
Task Force
OpenHAN
Task Force
UtilityAMI
Interest Group
NIST Conceptual Model
[Source: NIST Interim Roadmap]
[Source: NIST Interim Roadmap]
Business Drivers
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
Proprietary and Confidential
7
SG-Systems Working Group
Charter:
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, OMS, GIS, CIS, work management, etc.). Task forces are established on an as needed basis to accomplish these goals for specific functional areas.
SG-Systems WG Process Overview
Use Cases From SCE and others HomePlug & ZigBee SE 2.0 IEC TC57 WG14, OASIS, IEEE Other SDOs NIST System Requirements Specification (SRS) SG-Security WG Task Forces Use Case Development EPRI, MultiSpeak
Business-Oriented, Common Format Use Cases Based on SRS Reference Model
Service Definitions (supporting SDOs)
Recommendations to IEC TC57 WG14: •Proposed CIM Extensions •Message Schemas Updates •Requirements Updates Recommendations to other SDOs
SG-Conformity WG
•Integration Requirements •Patterns •Sequence Diagram •Services •WSDL
Key Collaboration Concept for the SG-Systems Working Group
Standard building blocks
Standards Development Organizations, and industry groups: are defined by IEC, other
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
industry standard building blocks
.
Ideas for recommended extensions and changes to standard building blocks are provided back to appropriate standards bodies.
SG-Systems WG February 2010
Our Focus: Finding/Developing
Best Practices
& Making Them into Vetted
“Industry Best Practices”
Utility’s Projects - Design & Implementations -------------- Utility’s Architecture ---------------------- Industry Best Practices Interoperability Testing ---------------------------------
Industry Best Practices
----------------------------------------- Standards Conformance & Interoperability Testing ----------------------------------------------------
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
Agenda
Introductions and Brief Overview of SG-Systems Requirements Gathering – Use Cases and System Requirements Overview with AMI-Ent example OpenADE OpenADR OpenHAN EIM Task Force General discussion, questions & answers Adjourn
Agenda
Introductions and Brief Overview of SG-Systems Requirements Gathering – Use Cases and System Requirements Overview with AMI-Ent example OpenADE OpenADR OpenHAN EIM Task Force General discussion, questions & answers Adjourn
Agenda
Introductions and Brief Overview of SG-Systems Requirements Gathering – Use Cases and System Requirements Overview with AMI-Ent example OpenADE OpenADR OpenHAN EIM Task Force General discussion, questions & answers Adjourn
Scope of HAN SRS in the NIST conceptual model
15
OpenHAN - Scope
AM I Ba ckha ul N etw ork Re gis ter ed Co nsu me r D evi ce (Se Hom Load Con trol cur e D ed) ispla y Plug -In H ybrid PCT D istrib uted Pre mise Mete r P rem ise Util ity (Se De vic cur e ed) Ene rgy S ervic es In terfa ce Prem ise E MS In Hom e Ligh ting Hea lth C are Util ity Pu (Ev blic ent Br s a oad nd cas pric t C han ign nel al) Co nsu me r D Exte rnal I nterfa ce Sm art e Set T op B ox evi ce
16
OpenHAN History
2007 2008 2009 2010 OpenHAN TF is formed to develop system requirements for the HAN August 2008 UtilityAMI 2008 HAN SRS v1.04 released June 2009 Utility AMI 2008 HAN SRS v1.04 selected as a customer domain standard in the NIST Smart Grid Interoperability Standards Roadmap Jan – July 2010 OpenHAN 2.0 collaboration effort August 30, 2010 UCAIug HAN SRS v2.0 ratified and released October 2009 OpenHAN 2.0 formed to develop the next version of the HAN SRS 17
OpenHAN 2.0 Effort
Over 130 individuals representing over 80 companies participated in the development of the HAN SRS v 2.0 over a 10 month period
Participating Companies
I’m in Control 4home DTE Energy Proto6 Aclara AEP APS Aridhio Technologies AT&T BC Hydro BGE BSH CPUC Capgemini Carrier CenterPoint Cisco Coincident, Inc Comverge, Inc. Consumers Energy Certicom Corp Deloitte Consulting DotUI Drummond Group DS2 Duke Eaton Ecologic Analytics, LLC Emerson /White-Rogers emeter Enernex EPRI FPL Ford GE General Motors Georgia Power Co. google Granitekey Gridata Inc heyCoop, LLC Home Automation, Inc Honeywell HP Hypertek Inc IBM Infineon Technologies Invaluable Technologies Itron Kaapco / ASR Systems KCP&L Konnected Universe LLC LG Electronics USA. Inc. LonMark International MicroSoft MultiSpeak NextGEN Consultancy Pvt. Ltd. N-Dimensions Solutions NV Energy Oncor Electric Delivery PA Consulting Panasonic Pentair Water Pool & Spa People Power PG&E Portland General Electric Progress Energy PSU Reliant Energy RIM Sacramento Municipal Utility District SCE Schneider Electric Southern Company Subzero SunSpec Alliance Tendril Trilliant UISOL U-SNAP Alliance Visible Energy Xtensible.net ZigBee Alliance
Documents Reviewed
Industry use cases were reviewed to identify any gaps
o o ZigBee+HomePlug SEP MRD SAE J2836/1™ J2836/2™ and J2836/3™ Use Cases o o o o o o NAESB Draft Requirements Specifications for NIST PAP03, PAP04, and PAP09 EIS Alliance Customer Domain Use Cases v1.0
CEC Requirements Engineering for the Advance Metering Infrastructure and the Home Automation Network (AMI-HAN) interface – February 2008 AHAM Smart Grid White Paper DER Contribution to OpenHAN; EPRI/DOE PV/Storage Communication Project Summary of Use Cases: For Demand Response Appliances Interface (EPRI Adapters)
February 2010 NISTIR 7628 Smart Grid Cyber Security Strategy and Requirements
UCAIug HAN SRS v2.0
Purpose
Define the system requirements for an open standard Home Area Network system Promote open standards-based HANs that are interoperable Provide the vendor community with a common set of principles and requirements around which to build products Ensure reliable and sustainable HAN platforms Support various energy policies in a variety of states, provinces, and countries Empower consumers to manage their electricity consumption by giving them the information and control they need to make decisions on their energy use 20
UCAIug HAN SRS v2.0
Architectural Considerations
HAN SRS applies from the edge of the AMI System, where the Energy Services Interface (ESI) resides, to all relevant HAN Devices in the premises Energy Services Interface (ESI) o o o o An interface which enables communication between authorized parties and HAN devices that are registered to it There may be more than one ESI in the premise (e.g. Utility ESI, 3 rd party ESI) Utility ESI – provides interface between the Utility AMI network and HAN devices, including the AMI meter Other ESI – provides interface between other communication media (e.g. internet, cell phone, EMS, etc.) and HAN devices registered to it 21
UCAIug HAN SRS v2.0
Architectural Considerations,
continued Commissioning, Registration, Enrollment o o o Commissioning is the process by which a HAN device obtains access to a specific physical network and allows the device to be discovered on that network Registration is the process by which a Commissioned HAN device is authorized to communicate on a logical network by exchanging security credentials with an ESI Enrollment is the process by which a Consumer enrolls a Registered HAN device in a Service Provider program (e.g. demand response, energy management, PEV program, etc.) 22
This figure shows the type of communication a HAN Device may engage in, which is dependent upon its relationship with the ESI and the Service Provider.
Energy Services Interface (ESI) Enrolled HAN Device (must be Registered) Registered HAN Device (must be Comissioned) Commissioned HAN Device Service Provider Network (e.g. AMI Network, Internet, etc.) Communication Types Service Provider Messages including Control Signals
(Two-way communications between Service Provider and Enrolled HAN Devices)
Consumer Specific Information
(One-way and Two-way communications between ESI and Registered HAN Devices as well as among Registered HAN Devices)
Public Information
(One-way communications to Commissioned HAN Devices)
Service Provider to ESI
(Two-way communications to the ESI which may elicit further communication between the ESI and Registered HAN devices and Public Information from the ESI to Commissioned HAN devices) 23
UCAIug HAN SRS v2.0
Architectural Considerations
, continued HAN SRS is agnostic to device ownership Some HAN devices may reside on more than one ESI HAN SRS is agnostic to electric market structure and is applicable to both integrated utility markets as well as consumer choice electric markets There may be multiple communication paths into the HAN (e.g. Utility AMI, internet, cell phone network, EMS, etc.) HAN SRS addresses the following special applications o o o Plug-in-Electric Vehicle (PEV) Energy Management System (EMS) Distributed Energy Resources (DER) 24
UCAIug HAN SRS v2.0
HAN System Requirements
Application Requirements Control applications respond to control signals Measurement and Monitor applications provide internal data and status Processing applications consume, process, and act on external and internal data Human Machine Interface (HMI) provides Consumers a means to provide input into an application or to view information from an application Communication Requirements Commissioning is the network process of adding a HAN device on the HAN to allow the device to communicate with other devices and involves network scanning, selection, admission, and configuration Control of a node involving self-organization, path selection, mitigation 25
UCAIug HAN SRS v2.0
HAN System Requirements,
continued Security Requirements Access Controls and Confidentiality address data protection for data-at rest and data-in-transit Registration is the network process to authenticate and authorize HAN device participation with an ESI and includes initialization, authentication, correlation, authorization, and de-register Enrollment is the process by which a Consumer enrolls a HAN device in a Service Provider’s program (e.g. demand response, energy management, pre-pay, PEV programs, distributed generation, pricing, messaging, etc.) and gives certain rights to the Service Provider to communicate with their HAN device Integrity preserves the HAN operating environment through resistance and recovery Accountability will allow for monitoring malicious activities through audit and non-repudiation 26
UCAIug HAN SRS v2.0
HAN System Requirements,
continued Performance Requirements Ensure applications or other factors do not limit the performance of the system, which is dependent upon availability, reliability, maintainability, scalability, upgradeability, quality and latency Operations, Maintenance, and Logistics Requirements Manufacturing and Distribution - Vendor’s pre-installation activities including pre-Commissioning settings, application configuration, labeling, support for multiple distribution channels Installation – Documentation for the physical placement of the device and support systems Manage, Maintain – ensure HAN device diagnostic, management and trouble shooting capabilities including alarming, logging, testing, device reset, and monitoring 27
Questions????
UCAIug HAN SRS v2.0
is located on the OpenHAN sharepoint: http://osgug.ucaiug.org/sgsystems/openhan/default.aspx
28
Agenda
Introductions and Brief Overview of SG-Systems (Greg) Requirements Gathering – Use Cases and System Requirements Overview with AMI-Ent example (Mark) OpenADE (Steve or Dave) OpenADR (Bruce) OpenHAN (Erich) EIM Task Force (Jim) General discussion, questions & answers Adjourn
Smart Grid Interoperability
Ability of systems to
operate in coordination
Ability to exchange and use information appropriately
Requires
standard interface definitions
Governed by open industry working groups
Provides Benefits
Promotes
loosely-coupled
integration Allows incremental functional enhancements Creates market for reusable, compatible components Only
one integration
instead of many To an open, public, standard interface Instead of each proprietary vendor or utility interface
Smart Grid Challenges
Requires Integration – LOTS of integration
Onslaught of new applications and technologies AMI, MDMS, HAN, DR, ADE, etc.
In a complex IT environment
Many custom systems, legacy technologies Typically departmentally controlled – within “silos” Need ability to govern, manage, and share resources at the Enterprise level and beyond (external services) Aging / outsourced systems and IT workforce Historically, extremely low R&D expenditures Must ramp up capabilities quickly Each utility has its own Software Development Life Cycle (SDLC)
It’s More Than Just Technical Matters
Driving Forces 1.
2.
3.
4.
5.
6.
7.
Consistent enterprise-wide data One version of the truth Access to data regardless of source Business transformation agility Reduced project implementation costs Reduced maintenance costs Reduced IT risks 8.
Availability of external services 9.
Scalable business process automation 10. Scalable business activity monitoring 11. Accurate reporting – regulatory, KPIs 12. Mergers and acquisitions Restraining Forces 1.
2.
3.
4.
5.
6.
7.
8.
9.
Lack of stable industry standard definitions Vendor’s way = lower project costs Vendors pushing for ‘proprietary lock-in’ Consultants pushing to be ‘thought leaders’ Hours-sold revenue driving System Integrators Internal system experts want to remain experts Project managers striving for control Inertia – why change?
Our situation’s unique – standards hinder us For further information, please refer to the article on page 56 of the January issue of Utility T&D Automation & Engineering: http://www.uae-digital.com/uae/200801/
Defining EIM (Gartner)
Enterprise Information Management (EIM) is:
An organizational commitment to structure, secure and improve the accuracy and integrity of information assets,
to solve semantic inconsistencies boundaries, across all and support the technical, operational and business objectives within the organization's enterprise architecture strategy .
A commitment to EIM is recognition that information in the enterprise is as important as process (application development) and infrastructure (technology)
Overall EIM Framework
Enterprise Vision & Strategy EIM Vision & Strategy Enterprise Architecture EIM Governance Vision Mission Strategy Goals & Objectives Value Propositions Sponsorship Stewardship Policies, Principles & Tenets Alignment Structure Enterprise Business & IT Core Processes EIM Core Processes Data Quality Data Integrity Data Security & Protection Data Lifecycle Management Data Movement Semantics Management Database Management Master Data Management Information Services Services & Support Enterprise Business & IT Organizations Enterprise Infrastructure EIM Organization CSFs & KPIs Structure (Virtual, Hybrid……) Roles & Responsibilities Functional Services Business Value and Relationship Management EIM Infrastructure Information Architecture Blueprint Management Technologies (DBMS, Content Mgmt, ETL, EAI, EII, Data Modeling, BI/DW, Collaboration…..) Knowledgebase and Repositories Standards & Best Practices
EIM
Charter
Identify and articulate common EIM requirements: Use cases Activity Diagrams EIM Requirements Specification Develop common EIM Framework that satisfies requirements, taking advantage of other relevant industry work as appropriate (e.g., vision, governance, processes, etc.) Develop requirements for an OpenSG generic semantic model to be used by members as a starting point for their enterprises.
Collaborate with SGAC of the NIST SGIP Provide a forum for exchanging information so that all members can benefit from lessons learned.
Collaborate with Standards Development Organizations (SDOs), NIST SGIP, and/or consortiums so that needed advancements are accomplished in the most appropriate organizations in the most efficient manner.
Slide 35
Agenda
Introductions and Brief Overview of SG-Systems (Greg) Requirements Gathering – Use Cases and System Requirements Overview with AMI-Ent example (Mark) OpenADE (Steve or Dave) OpenADR (Bruce) OpenHAN (Erich) EIM Task Force (Jim) General discussion, questions & answers Adjourn