“SG-Systems” (Smart Grid – Operational Applications Integration)

“Boot Camp” OverviewGreg Robinson,Co-Chair, SG-Systems

Brent Hodges,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

AMI-EnterpriseTask Force

SG ConformityWorking Group

SG NetworkTask Force

SG SystemsWorking Group

SG CommunicationsWorking Group

SG SecurityWorking Group

OpenADRTask Force

AMI-SecurityTask Force

Network InteropTask Force

Enterprise Info Mgmt

Task Force

OpenADETask Force

UtilityAMIInterest Group

ObserversEEI, UTC

EdgeConformance

EnterpriseConformance

SecurityConformance

CyberSec-InteropTask Force

Usability AnalysisTask Force

OpenHANTask Force

SG SimulationsWorking 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.

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 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 CaseDevelopment

System Requirements Specification (SRS)

Service Definitions(supporting SDOs)

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-ConformityWG

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 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

15

Scope of HAN SRS in the NIST conceptual model

OpenHAN - Scope

16

AMI Backhaul Network

Load ControlPCT

Plug-In Hybrid Advanced In

Home DisplayRegi

stered

Consum

er Devi

ce (Secu

red)

Utility Devi

ce

(Secured

)

Lighting Control

Smart ApplianceHealth Care

Set Top Box

Consum

er Devi

ce

Distributed

Generation

Utility Publ

ic Broa

dcast C

hannel

(Events a

nd pric

e sign

al)

Premise Meter

(e.g., Gas)

Premise

Electric Meter In Home Display

Premise EMS

Energy Services Interface

External Interface

(Internet)

17

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

20

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

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

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.

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????

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 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/

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

Slide 35

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.

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