Upload
inga
View
37
Download
0
Tags:
Embed Size (px)
DESCRIPTION
“SG-Systems” (Smart Grid – Operational Applications Integration) “Boot Camp” Overview. Brent Hodges, Chair, SG-Systems. Greg Robinson, Co-Chair, SG-Systems. Agenda. 3:00 Introductions and Brief Overview of SG-Systems (Greg) - PowerPoint PPT Presentation
Citation preview
“SG-Systems” (Smart Grid – Operational Applications Integration)
“Boot Camp” OverviewGreg Robinson,Co-Chair, SG-Systems
Brent Hodges,Chair, SG-Systems
Agenda 3:00 Introductions and Brief Overview of SG-Systems (Greg) 3:15 Requirements Gathering – Use Cases and System
Requirements Overview with AMI-Ent example (Joe or Shawn) 3:30 Service Definitions Process with AMI-Ent example (Shawn) 3:45 OpenADE (Steve or Dave) 4:00 OpenADR (Albert or Bruce) 4:15 OpenHAN (Mary or Erich) 4:30 EIM Task Force (Greg) 4:45 General discussion, questions & answers 5:00 Adjourn
New EIM
Task Force
NIST Conceptual Model
[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.
Proprietary and Confidential
The CIM is the Basis for a Common Systems Language for Utilities
One DictionarySupports Many Forms of Communication
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.
7
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
Use CaseTeam
System Requirements(SRS) Team
Service DefinitionsTeam
Use CasesFrom SCEand others
IEC TC57 WG14,OASIS, IEEEOther SDOs
NISTHomePlug & ZigBee
SE 2.0
•Integration Requirements•Patterns•Sequence Diagram•Services•WSDL
Business-Oriented,Common FormatUse Cases Based on SRS Reference Model
Recommendations to IEC TC57 WG14:•Proposed CIM Extensions•Message Schemas Updates•Requirements Updates
Recommendations to other SDOs
EPRI,MultiSpeak
SG-ConformityWorking Group
Task Forces
SG-SecurityWG
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 industry standard building blocks.
Ideas for recommended extensions and changes to standard building blocks are provided back to appropriate standards bodies.
February 2010 SG-Systems WG
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
Utility’sProjects
- Design &Implementations
---------------
Utility’sArchitecture
-----------------------Industry Best PracticesInteroperability Testing
---------------------------------
Industry Best Practices------------------------------------------
Standards Conformance & Interoperability Testing
-----------------------------------------------------Industry Standards SG-Systems WG
Agenda 3:00 Introductions and Brief Overview of SG-Systems (Greg) 3:15 Requirements Gathering – Use Cases and System
Requirements Overview with AMI-Ent example (Joe or Shawn) 3:30 Service Definitions Process with AMI-Ent example (Shawn) 3:45 OpenADE (Steve or Dave) 4:00 OpenADR (Albert or Bruce) 4:15 OpenHAN (Mary or Erich) 4:30 EIM Task Force (Greg) 4:45 General discussion, questions & answers 5:00 Adjourn
Agenda 3:00 Introductions and Brief Overview of SG-Systems (Greg) 3:15 Requirements Gathering – Use Cases and System
Requirements Overview with AMI-Ent example (Joe or Shawn) 3:30 Service Definitions Process with AMI-Ent example (Shawn) 3:45 OpenADE (Steve or Dave) 4:00 OpenADR (Albert or Bruce) 4:15 OpenHAN (Mary or Erich) 4:30 EIM Task Force (Greg) 4:45 General discussion, questions & answers 5:00 Adjourn
14
Scope of HAN SRS in the NIST conceptual model
15
OpenHAN History
2008
August 2008 UtilityAMI 2008 HAN SRS v1.04 released
2007
OpenHAN TF is formed to develop system requirements for the HAN
2009
June 2009Utility AMI 2008 HAN SRS v1.04 selected as a customer domain standard in the NIST Smart Grid Interoperability Standards Roadmap
October 2009OpenHAN 2.0 formed to develop the next version of the HAN SRS
2010
Jan – July 2010OpenHAN 2.0 collaboration effort
August 30, 2010UCAIug HAN SRS v2.0 ratified and released
Participating Companies
4home DTE Energy I’m in Control Proto6
Aclara Duke Infineon Technologies PSU
AEP Eaton Invaluable Technologies Reliant Energy
APS Ecologic Analytics, LLC Itron RIM
Aridhio Technologies Emerson /White-Rogers Kaapco / ASR Systems Sacramento Municipal Utility District
AT&T emeter KCP&L SCE
BC Hydro Enernex Konnected Universe LLC Schneider Electric
BGE EPRI LG Electronics USA. Inc. Southern Company
BSH FPL LonMark International Subzero
CPUC Ford MicroSoft SunSpec Alliance
Capgemini GE MultiSpeak Tendril
Carrier General Motors NextGEN Consultancy Pvt. Ltd. Trilliant
CenterPoint Georgia Power Co. N-Dimensions Solutions UISOL
Cisco google NV Energy U-SNAP Alliance
Coincident, Inc Granitekey Oncor Electric Delivery Visible Energy
Comverge, Inc. Gridata Inc PA Consulting Xtensible.net
Consumers Energy heyCoop, LLC Panasonic ZigBee Alliance
Certicom Corp Home Automation, Inc Pentair Water Pool & Spa
Deloitte Consulting Honeywell People Power
DotUI HP PG&E
Drummond Group Hypertek Inc Portland General Electric
DS2 IBM Progress Energy
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
Industry use cases were reviewed to identify any gapso ZigBee+HomePlug SEP MRDo SAE J2836/1™ J2836/2™ and J2836/3™ Use Cases o NAESB Draft Requirements Specifications for NIST PAP03, PAP04, and PAP09o EIS Alliance Customer Domain Use Cases v1.0o CEC Requirements Engineering for the Advance Metering Infrastructure and the
Home Automation Network (AMI-HAN) interface – February 2008o AHAM Smart Grid White Papero DER Contribution to OpenHAN; EPRI/DOE PV/Storage Communication Projecto Summary of Use Cases: For Demand Response Appliances Interface (EPRI
Adapters)
February 2010 NISTIR 7628 Smart Grid Cyber Security Strategy and Requirements
Documents Reviewed
18
UCAIug HAN SRS v2.0Purpose
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
19
UCAIug HAN SRS v2.0The audience for the HAN SRS include:
Utilities considering deploying AMI systems that interact with HANs Vendors that make AMI systems for Utilities that interact with HANs Vendors that make consumer products (e.g. programmable communicating
thermostats, energy management systems, load control switches, in-home displays, smart appliances, Plug-in Electric Vehicles (PEV), distributed energy resources (DER), etc.)
Service Providers developing smart grid enabled programs for consumers (e.g. demand response, energy management, pre-pay, PEV programs, DER programs, etc.)
Policy makers looking to understand how Utility AMI deployments that interact with HANs benefit and impact consumers
Industry alliances and standards organizations NIST Smart Grid Interoperability Panel (SGIP) activities (e.g. Smart Grid
Architectural Committee (SGAC), Cyber Security Working Group (CSWG), Smart Grid Testing and Certification Committee (SGTCC), etc.)
20
UCAIug HAN SRS v2.0Guiding Principles
Capabilities1. Supports two-way communication between HAN Devices and Service
Providers2. Supports load control integration3. The AMI meter provides the HAN with direct access to Consumer-
specific usage data4. Provides a growth platform for future products which leverage the HAN
and meter data5. Supports three types of messaging: Public Information, Consumer-
Specific Information, and Control Signals6. Supports end-use metering and other utility meters7. Supports distributed energy resources
Assumptions8. Consumer owns the HAN9. HAN devices present additional security considerations10. The HAN is enabled by open and interoperable standards
21
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 An interface which enables communication between authorized parties
and HAN devices that are registered to ito There may be more than one ESI in the premise (e.g. Utility ESI, 3rd
party ESI)o Utility ESI – provides interface between the Utility AMI network and HAN
devices, including the AMI metero Other ESI – provides interface between other communication media
(e.g. internet, cell phone, EMS, etc.) and HAN devices registered to it
22
Architectural Considerations, continued Commissioning, Registration, Enrollment
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
o 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
o 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.)
UCAIug HAN SRS v2.0
23
CommissionedNetwork admission of HAN
device on HAN
CommissionedNetwork admission of HAN
device on HAN
RegisteredAuthentication established
between HAN device and ESI
RegisteredAuthentication established
between HAN device and ESI
Pre-commissionedNon-HAN operation of devicePre-commissioned
Non-HAN operation of device
EnrolledService Provider granted rights
to access HAN device
EnrolledService Provider granted rights
to access HAN device
UCAIug HAN SRS v2.0
24
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 applicationso Plug-in-Electric Vehicle (PEV) o Energy Management System (EMS)o Distributed Energy Resources (DER)
UCAIug HAN SRS v2.0
25
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
UCAIug HAN SRS v2.0
26
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
UCAIug HAN SRS v2.0
27
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
UCAIug HAN SRS v2.0
28
UCAIug HAN SRS v2.0 is located on the OpenHAN sharepoint: http://osgug.ucaiug.org/sgsystems/openhan/default.aspx
Questions????
29
Appendix
30
Service Provider Network (e.g. AMI Network, Internet, etc.)
Energy Services Interface (ESI)
Enrolled HAN Device (must be Registered)
Commissioned HAN Device
Registered HAN Device (must be Comissioned)
Communication Types
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 Messages including Control Signals (Two-way communications between Service Provider and Enrolled 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)
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.
31
In order to provide guidance to service providers and vendors, the OpenHAN Task Force mapped each requirement to functional HAN Devices in tables at the end of each requirement section.
The tables indicate which requirements the OpenHAN Task Force considered necessary for the Commissioning Process (CP), for the Registration Process (RP), for Security (S), for application functionality (BF), as Optional (O), or if the requirement was Not Applicable (NA) for the function of the device.
These tables may be used as a template or starting point for Service Providers in their discussions with vendors and in their procurement process.
Vendors may use these tables as guidance for producing devices and software which enables basic HAN functionality and for providing additional functionality in order to provide competitive differentiation.
The tables are for reference only and should not limit the needs of Service Providers nor limit vendor innovation.
Mapping Requirements to Functional Devices
32
Mapping Requirements to Functional DevicesTable 3: Control Requirements Mapping
ID HAN System RequirementsUtility
ESIESI PCT IHD EMS
Load Control
AMI Mete
r
HAN Meter (non-
electric)
Smart Appliance
EVSE PEV EUMD
1 HAN Device shall accept Control Signals from one or more authorized parties (e.g. Utility, Service Provider, EMS, Consumer).
NA NA BF NA BF BF NA NA BF BF BF NA
2 HAN Device shall limit or reduce energy consumption in response to Control Signal receipt.
NA NA BF NA BF BF NA NA BF BF BF NA
3 HAN Device shall resume previous operational state (as appropriate) following receipt of Control Signal that cancels, expires, or overrides a previous Control Signal in effect
NA NA BF NA BF BF NA NA BF BF BF NA
4 HAN Device shall acknowledge receipt of Control Signal, when requested.
NA NA BF NA BF BF NA NA BF BF BF NA
5 HAN Device shall acknowledge execution of Control Signal, when requested.
NA NA BF NA BF BF NA NA BF BF BF NA
Agenda 3:00 Introductions and Brief Overview of SG-Systems (Greg) 3:15 Requirements Gathering – Use Cases and System
Requirements Overview with AMI-Ent example (Joe or Shawn) 3:30 Service Definitions Process with AMI-Ent example (Shawn) 3:45 OpenADE (Steve or Dave) 4:00 OpenADR (Albert or Bruce) 4:15 OpenHAN (Mary or Erich) 4:30 EIM Task Force (Greg) 4:45 General discussion, questions & answers 5:00 Adjourn
The Same Old Approaches Won’t Work!
The Smart Grid is about Smart Data Too many moving parts & too much investment at risk - to go on doing
“more of the same” IT practices Smart Data Requires:
Planned Enterprise Information Management (EIM) Based on an architecture with strong interfaces Makes practical use of industry standards Decouples projects
Architecture for incremental deployment over many years Master Plan implemented in phases Each increment must fit cohesively with previously installed components
Getting help by leveraging effective user organizations Lowers costs and mitigates risks for nominal cost
[Source: NIST Interim Roadmap]
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
It’s More Than Just Technical Matters
Driving Forces Restraining Forces
Sta
tus
Quo
1. Lack of stable industry standard definitions
2. Vendor’s way = lower project costs
3. Vendors pushing for ‘proprietary lock-in’
4. Consultants pushing to be ‘thought leaders’
5. Hours-sold revenue driving System Integrators
6. Internal system experts want to remain experts
7. Project managers striving for control
8. Inertia – why change?
9. Our situation’s unique – standards hinder us
1. Consistent enterprise-wide data
2. One version of the truth
3. Access to data regardless of source
4. Business transformation agility
5. Reduced project implementation costs
6. Reduced maintenance costs
7. 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
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/
Architecting for Successful Integration Semantics
Key to Success is Understanding What things need central planning What things can be left to the local developer/project team
Need to make active choices regarding: System structure and dynamics – cohesion & coupling Composition & decomposition Data life-cycle ownership across systems:
Message level (Work Order, Trouble Ticket) Object level (Crew, Switch, Asset)
Master planning is important Avoid falling into the trap of ‘Framework Bingo’ Use IEC 61968-1 IRM as a starting point for service portfolio planning Needs to be in the context of Enterprise Information Management
(EIM)
Incremental Development Used to engender a sense of joint ownership for the ultimate success
across the organization Users:
Provide feedback so that adjustments can be made impacting business functionality early in the program
Use part of the ‘to-be’ system, improving their confidence in the programme’s ability to deliver Suppliers:
Early identification of gaps improves ability for satisfactory resolutions within existing budget and schedule
Significant changes in underlying business requirements can also be managed, without the need for expensive re-work downstream.
Program staff Morale is improved as their confidence grows in their ability to deliver what the users want
within the commitments they’ve made Leads to greater enthusiasm and a sense of achievement as their productivity increases
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 across all boundaries, 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)
EIM Vision & Strategy
EIM Governance EIM Core Processes EIM Organization EIM Infrastructure
Enterprise Vision & Strategy
Enterprise Architecture
Enterprise Business & IT Core Processes
Enterprise Business & IT Organizations
Enterprise Infrastructure
Vision
Mission
Strategy
Goals & Objectives
Value Propositions
Sponsorship
Stewardship
Policies, Principles &
Tenets
Alignment
Structure
CSFs & KPIs
Structure (Virtual,
Hybrid……)
Roles & Responsibilities
Functional Services
Business Value and Relationship
Management
Information Architecture
Blueprint Management
Technologies(DBMS, Content Mgmt, ETL, EAI,
EII, Data Modeling, BI/DW, Collaboration…..)
Knowledgebase and Repositories
Standards & Best Practices
Data Quality
Data Integrity
Data Security & Protection
Data Lifecycle Management
Data Movement
Semantics Management
Database Management
Master Data Management
Information Services
Services & Support
Overall EIM Framework
Summary Points
The Smart Grid is about Smart Data Too many moving parts & too much investment at risk - to go on doing “more
of the same” IT practices Smart Data Requires:
Planned Enterprise Information Management (EIM) Based on an architecture with strong interfaces Makes practical use of industry standards Decouples projects
Architecture for incremental deployment over many years Master Plan implemented in phases Each increment must fit cohesively with previously installed components
Getting help by leveraging effective user organizations Lowers costs and mitigates risks for nominal cost
…
Agenda 3:00 Introductions and Brief Overview of SG-Systems (Greg) 3:15 Requirements Gathering – Use Cases and System
Requirements Overview with AMI-Ent example (Joe or Shawn) 3:30 Service Definitions Process with AMI-Ent example (Shawn) 3:45 OpenADE (Steve or Dave) 4:00 OpenADR (Albert or Bruce) 4:15 OpenHAN (Mary or Erich) 4:30 EIM Task Force (Greg) 4:45 General discussion, questions & answers 5:00 Adjourn