UtilityAMI OpenHAN TF

1
UtilityAMI OpenHAN TF

• HAN Guiding Principles, Use Cases, System
  Criteria
• Requirements Preparation Materials
• 15 August 2007

2
Introduction

• Purpose
• Information sharing (level setting)
• Validate approach
• Drive technology implementations
• Establish participation and responsibility
• Describes utilitys 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

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

4
Documentation Process (Ratified)
5
HAN Guiding Principles
Value Proposition
Use Cases
System Criteria
Platform Independent Requirements
Platform Requirements (Technology Specific)
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

7
HAN Use Cases
Value Proposition
Use Cases
System Criteria
Platform Independent Requirements
Platform Requirements (Technology Specific)
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)

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

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)

11
Load and Energy Management

• Three Scenarios
• Voluntary - covers load reduction at the
  customers 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

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/dischargin
  g 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 utilitys preferred
  configuration or communication for reliability
  programs. (e.g., utility may still require HAN
  device registration)

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
  utilitys).
• Assumptions and Notes
• Dependent on Submetering use case
• Energy 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

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 Notes
• Rapid updates to any IHD does not restrict AMI or
  other utility functionalities
• The 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

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

16
OpenHAN Use Case

• Use Case Ratification?

17
HAN System Criteria and Functional
Characteristics
Value Proposition
Use Cases
System Criteria
Platform Independent Requirements
Platform Requirements (Technology Specific)
18
HAN Functional Characteristics and System Criteria
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/hea
  ter 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)

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

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 utilitys network)
• Validation validates the applications 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 applications data (e.g., tamper
  and compromise resistance)
• Recovery restores an application or the
  applications 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)

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

23
HAN Operations, Maintenance and Logistics

• Manufacturing and Distribution - Vendors
  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

24
HAN Platform Independent Requirements
Value Proposition
Use Cases
System Criteria
Platform Independent Requirements
Platform Requirements (Technology Specific)
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

26
Requirements Process Proposal (continued)
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)