Aug 2007 1

UtilityAMI OpenHAN TF

HAN Guiding Principles, Use Cases, System CriteriaRequirements Preparation Materials

15 August 2007

Aug 2007 2

Introduction

Purpose: Information sharing (level setting) Validate approach Drive technology implementations Establish participation and responsibility 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 vendor clarification meetings and phone calls

Outline: Introduction Documentation process Guiding principles Use Cases System Criteria Next Steps (Requirements Composition)

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

System Criteria

Functional C

haracteristic

s

Platform

Independent

Requirements

OpenH

AN

Com

pliant

Use Cases

Aug 2007 4

Documentation Process (Ratified)

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

Ope

nHA

N D

ocum

enta

tion

Proc

ess

Technology Platforms and Alliances

Aug 15 Ratification Date

Examples: PUC, SOX, NERC, etc.

Ratified

Ratified

Aug 2007 5

HAN Guiding Principles

Value Proposition

Guiding Principles

Use Cases

Platform Independent Requirements

Platform Requirements

(Technology Specific)

System Criteria

Aug 2007 6

HAN Guiding Principles

Capabilities Supports a secure two way communication with the meter Supports load control integration Provides direct access to usage data Provides a growth platform for future products which leverage HAN

and meter data Supports three types of communications: public price signaling,

consumer specific signaling and control signaling Supports distributed generation and sub-metering

Assumptions Consumer owns the HAN Meter to HAN interface is based on open standards Implementation is appropriate given the value and the cost Technology obsolescence does not materially impact the overall value

Aug 2007 7

HAN Use Cases

Value Proposition

Guiding Principles

Use Cases

Platform Independent Requirements

Platform Requirements

(Technology Specific)

System Criteria

Aug 2007 8

Use Case Scope

Abstracted to highest level for rapid adoption (i.e., more details to follow) note: previous work has been more detailed

Concentrates on Utility to HAN interactions Device ownership independent (e.g.,

registration is the same whether or not the utility supplies the device)

Interactions are based on Utility relevant activities only (Ignores other HAN activities within the premise – e.g., Home Automation)

Required device functionality will be specified in subsequent phases (i.e., platform independent requirements)

Aug 2007 9

Organization

System Management and Configuration Depot Configuration Installation and Provisioning Utility Registration Remote Diagnostics Maintenance and Troubleshooting

Load Control and Energy Management Voluntary Mandatory Opt-out

Energy Management System Energy Storage and Distribution User Information Submetering

Aug 2007 10

System Management and Configuration

Five scenarios Depot Configurations – covers any manufacturer certification or configuration steps

needed for compliance/compatibility Installation and Provisioning - covers the activities associated with physical installation

and the admission to the local HAN Registration - covers the steps necessary admit a device to the Utility AMI network as

well as any high level consumer/device/application enrollments HAN Remote Diagnostics – covers the high level activities associated with utility

diagnostics HAN Device Diagnostics – covers on-site troubleshooting steps

Major assumptions and notes Network provisioning and registration have differing purposes and steps (e.g., network

vs. utility admission, security and directional authentication) Consumer consumption signaling requires registration (confidentiality and privacy) Utility control signaling requires registration Public Pricing does not require registration (i.e., needs one directional trust – network

commissioning) Registration requirements could impact manufacturing/depot configurations (implies

certification process) Mobility requirements are supported but not defined within these use cases (e.g.,

EV/PHEV premise/account/device bindings)

Aug 2007 11

Load and Energy Management

Three Scenarios Voluntary - covers load reduction at the customer’s site by communicating

instantaneous kWh pricing and voluntary load reduction program events to the customer

Mandatory – covers load and energy management scenario refers to demand response resources dispatched for reliability purposes

Opt-out – covers request to opt-our of the program due to a medical emergency/conditions

Assumptions and Notes The HAN device is capable of differentiating between emergency/reliability

and/or price-response event signals. Certain HAN devices can distinguish or support various event types and take

appropriate action based on the event. HAN Devices do not need to register with the Utility AMI system to obtain

Utility messaging (e.g. pricing events). However, the customer must enroll in a demand response program or tariff and must register the HAN device with the Utility for the HAN device to confirm its successful actuation of the event.

HAN Devices receive optional warning messages Mandatory events require gateway acknowledgement

Aug 2007 12

Energy Management System

Covers the utility to EMS interactions Assumptions and Notes

The EMS is aware of or can retrieve the types of HAN device types and the status of those devices connected to the HAN and upon registration or change-out. (e.g., fridge on/off)

EMS controls production, consumption and storage within the HAN. (e.g. Controls charging/discharging of an Electric Vehicle)

The EMS can be pre-programmed to respond to utility signals and commands. (e.g., reliability event)

Use case does not imply the utility’s preferred configuration or communication for reliability programs. (e.g., utility may still require HAN device registration)

Aug 2007 13

Energy Storage and Distribution

Covers the connection interaction of the premise Home Area Network (HAN), the Utility AMI system and the electric system (home, vendor or utility’s).

Assumptions and NotesDependent on Submetering use caseEnergy Supplying Unit (ESU) can be an energy

storage device (e.g., electric vehicle battery) or an energy generation device (e.g., photovoltaic array or backup generator).

Assumes that the Energy Supplying Unit (ESU) already contains energy

Aug 2007 14

User Information

Covers utility initiated messages and electric usage updates via an In Home Display (IHD) – does not cover other internal HAN display functions

Assumptions and NotesRapid updates to any IHD does not restrict AMI or

other utility functionalitiesThe IHD is either pre-programmed to respond

appropriately to price, consumption, load or event messages and/or the customer has manually programmed the IHD

The IHD indicates the status of the communication link with the Utility AMI gateway

Aug 2007 15

Submetering

Covers the measurement of other metering devices within the HAN

Assumptions and Notes: The AMI system supports Sub meter device-specific, consumer-

specific and location-specific rates/billing. (e.g., Electric Vehicle (EV), Plug in hybrid electric vehicle (PHEV)).

AMI system provides pricing information to the sub metering devices.

This use case also applies to other HAN devices with metering capabilities (e.g., other entity gas and/or water meters, EV sub-metering, PV sub-metering, etc.)

This use case assumes multi-lateral information sharing among utility distribution companies (e.g., supports mobility).

Device provides the customer (end user) with the appropriate information. (e.g. % of charge, current rate of consumption, etc)

The device provides the utility AMI gateway with the current energy requirement and task time to completion

Aug 2007 16

OpenHAN Use Case

Use Case Ratification?

Aug 2007 17

HAN System Criteria and Functional Characteristics

Value Proposition

Guiding Principles

Use Cases

Platform Independent Requirements

Platform Requirements

(Technology Specific)

System Criteria

Aug 2007 18

HAN Functional Characteristics and System Criteria

Applications

DirectControl

Cycling Control

Limiting Control

Distributed Generation

Submetering

EnvironmentState

Device State

EnergyCost

Energy Production

Energy Optimization

Energy Demand

Reduction

EnvironmentImpact

UserInput

UserOutput

ControlHuman

MachineInterface

MeasureMonitor

System*

Communications

Discovery Control

Announce

Respond

InitialIdentify

Identify

Authenticate

Configure

Organize

Optimize

Prioritize

Mitigation

Security PerformanceOperations

MaintenanceLogistics

Availability Reliability Maintain-

ability

Scalability Upgrade-

ability Quality

Lev

el 4

Lev

el 2

Lev

el 3

Lev

el 1

Integrity Account-

abilityRegistration

Authentication

AccessControl

Confidenti-ality

Public

Private

Utility

Initialization

Validation

Correlation

Resistance

Recovery

Audit

Non-Repudaition

Revocation

Pre-commision

Registrationconfig

Labeling

Document

Support

AlarmLogging

Testing

Reset

Installation ManufactureDistribute

Manage Maintain

Purchasing

Platform Independent Requirements

CommisionProcessing

Energy Consumption

Authorization

*Applies to devices and applications that connect to the AMI Network

Aug 2007 19

HAN Application Characteristics

Control - Applications that respond to control commands Direct - Turns load On or Off Cycling - Turns load On or Off at configurable time intervals Limiting - Turns load On or Off based on configurable thresholds

Measurement & Monitoring - Applications that provide internal data & status Distributed generation (DG) - Local energy input/output (kWh, kW, other energy values) Sub-metering - Device specific, end-use energy consumption or production (e.g. Consumer PHEV) Environmental State - Current local conditions (e.g., temperature, humidity, time, airflow, ambient light

level, motion) Device State - The current or historical state of the device (e.g., lights/fans/compressor/motor/heater are

on/off) Processing - Applications that consume, process and act on external and internal data. These

applications accept data from external systems and HAN measurement & monitoring applications. In general, these applications that have a higher level of complexity and cost.

Energy Cost - Calculates current and overall energy cost Energy Consumption - Calculates current and overall energy consumption Energy Production - Calculates current and overall energy Production Energy Optimization - Utilizes external and HAN data to determine desired response based on a

consumer configurable profile Energy Demand Reduction - Uses external and HAN data to reduce load based on a consumer

configurable profile Environmental Impact - Calculates environmental impact of current energy consumption (e.g. Power

Generation Plant CO2 emissions related to consumer specific load) Human Machine Interface (HMI) - Applications that provide local user input and/or output.

These applications are based constrained and based on the data type User Input - Provides consumers with a means to input data into an Application (e.g., Touch screen,

Keypad) User Output - Provides an Application with a means to output data to the consumer (e.g., In-Home

Display, text message)

Aug 2007 20

HAN Communications

Discovery - The identification of new nodes within the HAN Announcement – both active and passive device notification methods Response - Includes both endpoints (e.g., announcing entity and recipient

entity) Initial Identification - Device-type and address identification

Commissioning - The network process of adding or removing a node on the HAN with the expectation that the system is self-organizing (i.e., initial communication path configuration). This process is decoupled from utility registration. Identification - Uniquely identifying the device Authentication - Validation of the device (e.g., the network key) Configuration - Establishing device parameters (e.g., network ID, initial path,

bindings) Control Autonomous functions enabled by the platform specific

technology Organization - Communication paths (e.g., route) Optimization - Path selection Prioritization - Communication based on importance (e.g., queuing,

scheduling, traffic shaping) Mitigation - Ability to adapt in response to interference or range constraints

through detection and analysis of environmental conditions

Aug 2007 21

HAN Security

Access Controls and Confidentiality – protection methods associated with both data-at-rest and data-in-transit based on data type Public Controls (low robustness) - protection methods for publicly available information

(e.g., energy price) Private Controls (medium robustness) - protection methods for confidential or sensitive

data (e.g., consumer usage) Utility Controls (high robustness) - protection methods for utility accountable data (e.g.,

load control, sub-metering data) Registration and Authentication – Verifying and validated HAN participation

Initialization – establishes the application/device as a validated node (i.e., logical join to the utility’s network)

Validation – validates the application’s data (i.e., request or response) Correlation – correlating an account (e.g., consumer) with a device, application or

program (e.g., DR programs, peak time rebate, etc.) Authorization – rights granted to the applications Revocation – removing an established node, correlation or authorization

Integrity – Preserves the HAN operating environment Resistance – methods which prevent changes to the application or application’s data

(e.g., tamper and compromise resistance) Recovery – restores an application or the application’s data to a previous or desired state

(e.g., reloading an application, resending corrupted communications) Accountability – monitoring malicious activities

Audit – application log detected compromise attempts Non-repudiation – applications and application operators are responsible for actions

(e.g., can not deny receipt or response)

Aug 2007 22

HAN Performance

Availability - The applications are consistently reachable

Reliability - The applications are designed and manufactured to be durable and resilient

Maintainability - The applications are designed to be easily diagnosed and managed

Scalability - The system supports a reasonable amount of growth in applications and devices

Upgradeability - The applications have a reasonable amount of remote upgradeability (e.g., patches, updates, enhancements)

Quality - The applications will perform as advertised

Aug 2007 23

HAN Operations, Maintenance and Logistics

Manufacturing and Distribution - Vendor’s pre-installation activities Pre-commissioning - Depot level configuration setting Registration configuration - Any required utility specific

configurations Labeling - Utility compliance and standards labeling Purchasing - Supports multiple distribution channels (e.g., retail,

wholesale, utility) Installation - physical placement of the device

Documentation - Installation materials and manuals Support Systems - Installation support systems including web

support, help line, other third party systems Management and Diagnostics

Alarming and logging - Event driven consumer and utility notifications

Testing - System and device testing Device reset - Resets the device to the installation state

Aug 2007 24

HAN Platform Independent Requirements

Value Proposition

Guiding Principles

Use Cases

Platform Independent

Requirements

Platform Requirements

(Technology Specific)

System Criteria

Aug 2007 25

Requirements Process Proposal

Determine Participation and Responsibility Review relevant use case(s) Review system criteria and organizing framework For each level four category generate basic platform independent

requirements For each level four category generate advanced (optional)

platform independent requirements Record motivating use case for fine-grain traceability (coarse

traceability is inherent in the process) Organization of Each Section:

Context (Overview, Architectural Drawings, Application of Requirements, etc.)

Basic Requirements Advance Requirements

Use OpenHAN TF Vetting Process

Aug 2007 26

Requirements Process Proposal (continued)

Applications

ControlHuman

MachineInterface

MeasureMonitor

Registration

Communications

Discovery Control

Security PerformanceOperations

MaintenanceLogistics

Availability Reliability Maintain-

ability

Le

vel 2

Le

vel 3

Use

Ca

se

Integrity Account-

abilityRegistration

Authentication

AccessControl

Confidenti-ality

Installation ManufactureDistribute

Manage Maintain

CommisionProcessing

Installation and Provisioning

Depot Configuraiton

Maintenance and Troubleshooting

Remote Diagnostics

Le

vel 4

See System Criteria for Level 4 Details

Bas

icA

dv

anc

ed

Req

uir

emen

ts

Requirements Analysis

Submetering

User Information

Load and Energy Management

EMS

Energy Storage and Distribution

Aug 2007 27

Next Steps

Ratify High Level System Uses (OpenHAN Use Cases) Develop OpenHAN platform independent requirements Ratify Requirements Continue to share information with technology

communities (i.e., vendors, alliances)