June 2007 1

California Investor Owned Utilities (IOU)

HAN vision statement development

15 June 2007

June 2007 2

Introduction

Purpose: Information Sharing Validate approach Establish responsibility and participation

Outline: Framework Introduction Documentation Purpose Documentation Process Technology Drivers Functional Characteristics and System Criteria Communication Example Security Example Next Steps

June 2007 3

Utility HAN Framework

Based on Strategic Planning and System Engineering

Each level provides direction and context for lower level

Delineates participation and accountability Can be mapped to GridWise Architecture

Framework (Loosely coupled - Decomposition framework vs. organizational interoperability view)

Stakeholder considerations at every level: regulators, consumers, utilities, vendors

Organizational

Economic | Policy

Objectives | Procedures

Technical

Connectivity

Syntactic | Network

Informational

Context | Semantics

GridWise Interoperability FrameworkHAN Lif

ecycle

Hierarch

y

Value

Proposition

Vision &

Guiding Principles

Platform

Requirements

(Technology Specific)

Functional

Characteristic

s &

Criteria

Platform

Independent

Requirements

openHA

N C

ompliant

June 2007 4

Document Purpose

Describes utility’s view of HAN Establishes participation scope and scale Intended audience:

Regulators – establish position, clarify roles and responsibility

OpenHAN – creates input for further system refinement (e.g., platform independent requirements, use cases)

Vendors – shows approach, motivation Establishes a baseline Time management: cuts down on clarification

meetings and phone calls

June 2007 5

Documentation Process

SCE Value Proposition

SDG&E Value Proposition

PG&E Value Proposition

Bus

ines

s N

eeds

Business Continuity Needs

Assessment

RegulatoryCompliance

Analysis

Prog

ram

Nee

ds

Common Purpose Common Vision

Indu

stry

Ena

bler

s

Common Principles

CA IOUValidation

Compliance Validation

Use Cases

OpenHAN Vetting and Refinement

System Criteria

OpenHAN Assessment

Platform Independent Requirements and Architecture

CA

IOU

HA

N D

ocum

enta

tion

Proc

ess

Technology Platforms and Alliances

OpenHAN Authorship

Examples: CPUC, CEC, NERC, etc.

June 2007 6

HAN Technology Drivers

Utility Value Proposition Provides justification Utility specific

Vision Statement End state vision based on utility’s mission Creates value and opportunity for all stakeholders

Guiding Principles Organized as capabilities and constraints Establishes the parameters for a two way communication interface with the meter Sets the boundaries of the system Establishes ownership High level expectations for functionality (e.g., load control, price signaling) Establishes handling expectations (e.g., security, signal types)

Standards Open source Applied at each level Can be constrained from the level above

June 2007 7

Functional Characteristics and System Criteria

Criteria and characteristics provides non authoritative context and clarification Viewed as technology enablers Driven by Guiding principles and use cases Establishes high level technical expectations Organized by behavior and function Includes Application, Communications, Security and Privacy and Performance

Application Criteria Utility functionality Know consumer functionality Application evolution and migration

Communication Criteria Logical and physical communication decoupling (AMI Backhaul and HAN) Interoperability and interference (e.g., customer gateways, networks) Communication evolution

Security and Privacy Graduated model (low, medium, high robustness) based on signal type Authentication, Authorization and Accountability

Authentication material: source, distribution flows Authorization (rights): device registration, participation and revocation Accountability: audit, alerts and non-repudiation

Performance (Adaptability, Flexibility, Scalability, Reliability, etc.)

June 2007 8

Communication Specification Example

ValueProposition

Vision &Guiding Principles

Functional Characteristics &

Criteria

Platform Independent Requirements

Platform Requirements (Technology Specific)

openHA

N C

ompliant

- Enable Demand Response- Enable energy information for customers without internet access- Satisfy higher customer experience expectations - Enable energy innovation for customers

- Provide secure two-way communications- Support command and control signaling- Support consumer specific signaling - Support ownership model

- Provide an agile communication capability - Provide adequate capacity - Provide communication reliability - Provide adequate communication control

- Requirements: Shall not interfere with other networks- Requirements: Shall allow coordination/control transfer - Requirements: Shall provide product interoperability - Architecture: Define communication control

- Shall be 802.15.4 (Low Rate WPAN) compliant - Shall be IEEE P1901 compliant- Shall use direct-sequence spread spectrum coding- Shall use deficit weighted round robin (DWRR) for scheduling

Utility Specific

Example Needs and Requirements

June 2007 9

Security Specification Example

ValueProposition

Vision &Guiding Principles

Functional Characteristics &

Criteria

Platform Independent Requirements

Platform Requirements (Technology Specific)

openHA

N C

ompliant

- Enable Demand Response- Enable energy information for customers without internet access- Satisfy higher customer experience expectations - Enable energy innovation for customers

- Provide secure two-way communications- Support command and control signaling- Support consumer specific signaling - Support customer ownership model

- Provide a robust cryptographic capability for load control signaling - Provide a cryptographic capability for energy information sharing - Provide a secure device registration and authentication capability- Provide a robust audit capability

- Requirements: Shall use FIPS 197 (AES) for symmetric cryptography- Requirements: Shall use third party materials for authentication - Architecture: Define Commissioning and registration process- Architecture: Define Command and Control Signaling

- Shall use MAC layer security as specified in 802.15.4 - Shall use CCM mode (Counter with CBC-MAC) for block ciphers- Shall fully support EAP-PSK (RFC 4764)- Shall use EAP-TLS, defined (RFC 2716)

Utility Specific

Example Needs and Requirements

June 2007 10

Next Steps

Publish CA IOU vision statement Develop OpenHAN comprehensive HAN use cases Develop OpenHAN platform independent requirements Develop UtilityAMI platform independent architectural

views for AMI and HAN Continue to share information with technology

communities (i.e., vendors, alliances)