Dec 2007 1

UtilityAMI OpenHAN TF

Requirements Working Group

Specification Briefing

December 2007

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

Dec 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

Dec 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

Examples: PUC, SOX, NERC, etc.

Ratified

Ratified Ratified

Dec 2007 5

HAN Guiding Principles

Value Proposition

Guiding Principles

Use Cases

Platform Independent Requirements

Platform Requirements

(Technology Specific)

System Criteria

Dec 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

Dec 2007 7

HAN Use Cases

Value Proposition

Guiding Principles

Use Cases

Platform Independent Requirements

Platform Requirements

(Technology Specific)

System Criteria

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

Dec 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 HAN Metering

Dec 2007 10

Platform Independent Requirements

Value Proposition

Guiding Principles

Use Cases

Platform Independent

Requirements

Platform Requirements

(Technology Specific)

System Criteria

Dec 2007 11

Requirements working group feedback (Principles and Architecture)

Dec 2007 12

Feedback

Ownership rewind Original statement overloaded Confuses ownership, with accountability and control

Propose new guiding principle Consumer owns the premise Utility accountability is limited to register devices

Inferred Architectural principles Utilities support two logical interfaces (public interface and the private

interface) There are two logical networks within the premise (the utility network and any

third party network) The utility private network is formed through registration (device must comply

with requirement in order to be registered) Translation (i.e., a gateway) is required in order to move data between

networks (this function can be a part of any HAN device) Certain elements are not architecturally relevant:

Device ownership - requirements are universally applicable Third party gateways – does not impact OpenHAN architecture Physical transport - both networks (public and private) can share the same physical

transport (separation is logical and separates the applications)

Dec 2007 13

Clarify Architectural Assumptions

Dec 2007 14

Scenario 1: Inception

AMI Backhaul Network

PCT

Consum

er Utility

Intera

ctive A

pplica

tions

Utility Publ

ic Broa

dcast

Channel

(e.g,.,

price s

ignal)

AMI Gateway

Utility Owned and Operated

Dec 2007 15

Scenario 2: PCT and Gas Meter

AMI Backhaul Network

PCT

Consum

er Utility

Intera

ctive A

pplica

tions

Utility Appl

ication

s

Utility Publ

ic Broa

dcast

Channel

(e.g,.,

price s

ignal)

Revenue Grade

Electric Meter

AMI Gateway

Utility Owned and Operated

Dec 2007 16

Scenario 3: Mature Utility HAN

AMI Backhaul Network

Load ControlPCT

Certified Plug-In Hybrid Advanced IHDCons

umer

Utility Int

eractiv

e Appl

ication

s

Utility Appl

ication

s

Certified DG

Utility Secu

red Com

municat

ion

Channel

Utility Publ

ic Broa

dcast

Channel

(e.g,.,

price s

ignal)

Revenue Grade

Electric Meter

Revenue Grade

Non-electric Meter

AMI Gateway

Utility Owned and Operated

Dec 2007 17

Scenario 4: Utility HAN + HA

AMI Backhaul Network

Load ControlPCT

Certified Plug-In Hybrid Advanced IHDCons

umer

Utility Int

eractiv

e Appl

ication

s

Utility Appl

ication

s

Lighting Control

Smart Appliance

HA Controller

(e.g., Set Top Box)

Consum

er Appl

ication

s

Certified DG

Utility Secu

red Com

municat

ion

Channel

Utility Publ

ic Broa

dcast

Channel

(e.g,.,

price s

ignal)

Revenue Grade

Electric Meter

Revenue Grade

Non-electric Meter

AMI Gateway

Utility Owned and Operated

Dec 2007 18

Scenario 5: Utility HAN + EMS + HA

AMI Backhaul Network

Load ControlPCT

Certified Plug-In Hybrid Advanced IHDCons

umer

Utility Int

eractiv

e Appl

ication

s

Utility Appl

ication

s

Lighting Control

Smart ApplianceHome Health Care

HA Controller

(e.g., Set Top Box)

Consum

er Appl

ication

s

Certified DG

Utility Secu

red Com

municat

ion

Channel

Utility Publ

ic Broa

dcast

Channel

(e.g,.,

price s

ignal)

Revenue Grade

Electric Meter

Revenue Grade

Non-electric MeterHome Security

Certified

Premise EMS

Utility Application

Gateway

AMI Gateway

Utility Owned and Operated

Dec 2007 19

Scenario 6: Mature System

AMI Backhaul Network

Load ControlPCT

Certified Plug-In Hybrid Advanced IHDCons

umer

Utility Int

eractiv

e Appl

ication

s

Utility Appl

ication

s

Lighting Control

Smart ApplianceHome Health Care

HA Controller

(e.g., Set Top Box)

Consum

er Appl

ication

s

Certified DG

Utility Secu

red Com

municat

ion

Channel

Utility Publ

ic Broa

dcast

Channel

(e.g,.,

price s

ignal)

Revenue Grade

Electric Meter

Revenue Grade

Non-electric MeterHome Security

Certified

Premise EMS

Utility Application

Gateway

Other Premise

Gateway(Internet)

AMI Gateway

Utility Owned and Operated

Dec 2007 20

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

Format: IEEE 830 Use OpenHAN TF Vetting Process

Dec 2007 21

HAN Requirements Organization 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

Control

Announce

Respond

Identify

Authenticate

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

Payment

Dec 2007 22

HAN Requirements Organization and Use Cases

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

Dec 2007 23

Requirements Overview

Requirements are platform independent Requirement are to products applied via device

mappings Device mappings use required, enhanced, n/a

(removed enhanced and may designation from requirements list)

Special class of requirements for an AMI gateway Two types of compliance

Technology/alliance – application and communication compliance (e.g., message structures)

Vendor/product – compliant with device mapping requirements

Dec 2007 24

Application: Control

1. HAN Device shall accept control signals from the Utility.2. HAN Device shall respond to requests to cease operational state (e.g., open contact).

3. HAN Device shall respond to requests to resume operational state (e.g., close contact).

4. HAN Device shall acknowledge receipt of control signal.5. HAN Device shall acknowledge execution of control request.6. HAN Device shall acknowledge execution failure of request (i.e., exceptions). 7. HAN Device shall signal any consumer-initiated overrides. 8. HAN Device shall respond to request to cease operation state at a specific time. 9. HAN Device shall respond to request to resume operation state based at a specific time.

10. HAN Device shall delay restoration of operational state based on a pre-configured time (e.g., random number).

11. HAN Device shall respond to request to cycle operational state (i.e., duty cycle). 12. HAN Device shall respond to request to limit operational state based on thresholds, set-

points or triggers (e.g., price points). 13. HAN Device shall respond to requests for variable output (e.g., load limiting, energy

savings mode)

Dec 2007 25

Application: Measurement

1. HAN Device shall measure instantaneous demand (e.g., W).2. HAN Device shall measure accumulated consumption (e.g., Wh).3. HAN Device shall measure accumulated production (e.g., Wh).4. HAN Device shall measure consumption per interval (e.g., Wh, BTU, HCF). 5. HAN Device shall measure production per interval (e.g., Wh). 6. HAN Device shall store intervals measurements (e.g., 30 days of interval reads).

7. HAN Device shall allow interval configuration (e.g., 15 Minutes). 8. HAN Device shall monitor energy state (e.g., state of charge). 9. HAN Device shall measure available capacity (e.g., W, Volt-Amps). 10.HAN Device shall monitor the operational mode (e.g., charging, discharging).11.HAN Device shall measure power quality (e.g., frequency, neutral voltage,

harmonic content).12.HAN Device shall monitor environmental state (e.g., temperature, motion, wind).13.HAN Device shall monitor the operational mode of other devices (e.g., duty

cycle).14.HAN Device shall monitor environmental impact (e.g., CO2).

Dec 2007 26

Application: HMI

1. HAN Device shall provide visual indicators which indicate operational state (e.g., commissioned, registered, event status, device state).

2. HAN Device shall provide a power cycle input, which reboots the device.3. HAN Device shall provide a user reset input, which returns the device to its pre-installation state

(e.g., button). 4. HAN Device shall provide an alphanumeric display which indicates operational state (e.g., LCD

screen). 5. HAN Device shall provide non-visual sensory feedback (e.g., motion, vibration, audible).6. HAN Device shall provide a sight and hearing impaired interface.7. HAN Device shall provide a user-configurable display. 8. HAN Device shall accept user configurations. 9. HAN Device shall accept user preferences (e.g., Celsius/Fahrenheit, color). 10. HAN Device shall provide alarm notifications (e.g., price threshold, event messages).11. HAN Device shall accept Utility data source configurations (e.g., AMI Gateway, other HAN Devices).

12. HAN Device shall display Utility data source configurations (e.g., AMI Gateway, other HAN Devices).

13. HAN Device shall display application-specific information (e.g., cost, consumption, environmental impact, payment credit, remaining account credit).

14. HAN Device shall accept application-specific configurations (e.g., preconfigured periods (e.g., hour, day, week), configurable periods (e.g., interval length, TOU period), variable periods (e.g., Critical Peak Price period).

15. For battery-powered devices, HAN Device shall provide a battery life indicator.16. HAN Device shall accept payment data from the consumer.

Dec 2007 27

Application: Processing

1. The application shall calculate a HAN Device’s energy cost of accumulated energy consumption as monetary value (e.g., $/kWh * accumulated kWhrs = $).

2. The application shall calculate a HAN Device’s energy cost of instantaneous power consumption as a monetary value per time interval, (e.g., $/Wh * instantaneous W= $/hr).

3. The application shall calculate a HAN Device’s cost for Hourly Energy rates.

4. The application shall calculate a HAN Device’s energy cost for rate tiers/energy blocks.

5. The application shall calculate a HAN Device’s energy cost for Time-of-Use (TOU) energy rates.

6. The application shall calculate a HAN Device’s cost for Critical Peak Pricing (CPP).

7. The application shall calculate a HAN Device’s cost for capacity billing rates.

8. The application shall calculate costs for other billing determinants (e.g, monthly customer charges, taxes & franchise fee, surcharges, discounts, ratcheted demand, bond charges).

9. The application shall accept aggregated consumption and rate information from user-configurable sources (e.g., AMI Gateway, AMI System, and/or HMI).

10. The application shall calculate and forecast a HAN Device’s consumption based on user-defined parameters (e.g., estimated kWh/mon).

11. The application shall calculate and forecast a HAN Device’s production based on user-defined parameters (e.g., estimated kWh/mon).

Dec 2007 28

Application: Processing 2

12. The application shall forecast a HAN Device’s estimated cost calculation based on user-defined parameters (e.g., monthly consumption at current rate/usage).

13. The application shall calculate a HAN Device’s consumption based on user-defined parameters (e.g., historical reporting).

14. The application shall calculate a HAN Device’s production based on user-defined parameters (e.g., historical reporting).

15. The application shall calculate and/or predict a HAN Device’s environmental impact based on user-defined parameters (e.g., historical carbon footprint, forecasted carbon credits earned).

16. The application shall supply a method for local billing resolution (e.g., orphaned billing charge, consumption debits/credits).

17. The application shall calculate and suggest methods to optimize energy consumption and cost based on user-defined parameters (e.g., PCT thresholds, lighting settings, pool pump cycling).

18. The application shall calculate a HAN Device’s relative efficiency (e.g., comparison can be based on historical data, baseline at install, manufacturer’s parameters, industry/governmental standards, other devices, other premises).

19. The application shall calculate available load for demand reduction based on user-defined parameters (e.g., percentage of load available for various response scenarios).

20. The application shall calculate user-defined thresholds for consumption, production, and cost (e.g., if aggregated consumption reaches a certain level, an alert is generated).

Dec 2007 29

Communications: Commissioning

1. HAN Device shall accept network configuration data which allows for private Utility networking (e.g., private address/ID)

2. HAN Device shall accept commissioning configuration data by the manufacturer (e.g., link key).

3. HAN Device shall accept commissioning configuration from the Installer. 4. When a HAN Device is triggered (e.g., Allow Join Command), HAN Device location-specific/contact-

specific data shall be provided to other HAN Devices in the premise.5. When a HAN Device is triggered (e.g. Power-on, button), HAN Device shall provide the AMI

Gateway with device specific information including device ID and device type.6. When a HAN Device is triggered (e.g. power on, button), HAN Device shall provide the AMI

Gateway with device specific Utility information, including network ID, gateway ID, and Utility ID, if pre-configured with Utility information.

7. HAN Device shall have the ability to accept or reject the request based on device type.8. HAN Device shall have the ability to accept or reject device requests based on Utility specific

information, including network ID, gateway ID, and Utility ID. 9. HAN Device shall acknowledge successful commissioning requests (i.e., provide acknowledgement

to the requesting HAN Device).10. When a HAN Device is communicating with the AMI Gateway, HAN Device shall indicate link

connectivity. 11. HAN Device shall provide notification to the Installer of the commissioning status. Status conveyed

shall be either: successful/unsuccessful. 12. HAN Device shall maintain an updated list of commissioned (i.e., connected) HAN Devices.13. HAN Device shall have the ability to remove HAN Devices from the Utility HAN.

Dec 2007 30

Communications: Control

1. HAN Device shall accept network organization messages from the AMI Gateway (e.g., gateway location, routing table, address).

2. HAN Device shall accept network organization messages from peer devices (e.g., hidden node).

3. HAN Device shall use the most reliable path to the AMI Gateway (e.g., based on signal strength/quality).

4. HAN Device shall only use routes within its logical network (e.g., network ID, address scope, Utility ID).

5. HAN Device shall support prioritization of traffic (e.g., queuing, scheduling, traffic shaping). 6. HAN Device shall have the ability to automatically adapt to communications interference through

detection and analysis of environmental conditions (e.g., channel hopping, channel avoidance, signal-to-noise ratio).

7. HAN Device shall have the ability to automatically adapt to range constraints through detection and analysis of environmental conditions (e.g., change modulation schemes, change power output levels).

8. HAN Device shall include a data integrity mechanism for all communications.9. HAN Device shall have the ability to activate and deactivate its HAN communication.10. HAN Device shall communicate its availability (i.e., ‘heartbeat’) to the AMI Gateway at least once per

day.11. HAN Device shall have a configurable availability communication (i.e., heartbeat) frequency to the

AMI Gateway. 12. HAN Device shall store a list of available HAN Devices in the premise and make that list available to

the AMI System upon request.

Dec 2007 31

Security: Access

1. HAN Device shall provide access control to Utility applications, data, and services (e.g., control data, consumer-specific consumption data).

2. HAN Device shall control access to persistent Utility HAN data (data at rest).3. HAN Device shall control access to transmitted Utility HAN data (data in transit).4. HAN Device shall provide protection of Utility HAN data while being processed (data in processing)

(e.g., trusted processor). 5. HAN Device shall control access to data in accordance with a configurable Utility security policy

(e.g., users, applications, devices, data access-read/write).6. HAN Device shall provide mechanisms to enforce a policy based on least privilege (i.e., explicit

authorization).7. HAN Device shall have the ability to enforce policy periods (time constraints) for security policy

elements (e.g., maintenance/firmware window). 8. HAN Device shall control access to data in accordance with a configurable Utility security policy (e.g.,

users, applications, devices). 9. HAN Device shall provide methods to query and report access control data settings.10. HAN Device shall provide access control methods which prevent known attacks, including replay,

man-in-the-middle, delay, spoofing, sequence change, and deletion attacks.11. HAN Device shall implement mechanisms to prevent unintended disclosure of source/originator data

to unauthorized principals. 12. HAN Device shall implement controls which limit access to audit information.13. HAN Device shall support confidentiality and access controls that employ cryptographic operations

(e.g., digital signatures).14. HAN Device shall support confidentiality and access controls that employ cryptographic keys for only

one purpose (e.g., encryption authentication, or digital signatures).

Dec 2007 32

Security: Integrity

1. HAN Device shall protect the integrity of the HAN system (e.g., shall not adversely impact the operations of the HAN system by introducing malicious or unintended activity).

2. HAN Device shall provide a configurable HAN filtering function that filters based on allowable message types.

3. HAN Device shall provide a configurable HAN filtering function that filters messages based on structural integrity of the message.

4. HAN Device shall provide a configurable HAN filtering function that filters based on allowable message rates.

5. HAN Device shall detect unauthorized modification of data during storage (e.g., check sums, hashes, software attestations).

6. HAN Device shall detect unauthorized modification of data during network transit (e.g., check sums and hashes).

7. HAN Device shall attempt to correct unauthorized modification of data (e.g., resend).

8. HAN Device shall detect unauthorized modification of data attributes (e.g., modification to a message type).

9. HAN Device shall attempt to correct unauthorized modification of data attributes.

10. HAN Device shall only accept data from an authorized source (e.g., AMI Gateway, certified EMS).

11. HAN Device shall protect the system from malicious code (e.g., buffer overflow protection, limit executable code exposure).

12. HAN Device shall detect known attacks, including replay, man-in-the-middle, delay, spoofing, sequence change, and deletion attacks.

13. HAN Device shall separate security critical functionality and data from non-security critical system data.

14. HAN Device shall validate the source of HAN security policy.

15. HAN Device shall detected unauthorized modification of HAN security policy.

16. HAN Device shall detect unauthorized modification of audit data.

17. HAN Device shall validate the integrity of all software updates, including source, structure, and version.

18. HAN Device shall use tamper-resistant hardware (e.g., epoxy, TPM).

Dec 2007 33

Security: Accountability

1. HAN Device shall alert the AMI Gateway of all detected, security –related activities, including access control, authentication, and integrity violations.

2. HAN Device shall audit and store all security-related activities, including access control, authentication, registration, and integrity violations.

3. HAN Device shall provide, at a minimum, the following information for all detected security events: date and time of the event, type of event, device/user identity.

4. HAN Device shall provide the AMI System access to audit data. 5. HAN Device shall provide non-repudiation mechanisms for devices and users.6. HAN Device shall provide a mechanism for source identification of data (e.g., HAN and

AMI System data).7. HAN Device shall provide the capability to audit both system and user operations as

defined by the HAN security policy.8. HAN Device shall provide the ability to perform searches, sorts and filters of audit data

based on date and time, type and/or user identity.9. HAN Device shall provide the capability to identify mandatory and configurable audit

elements (In this context, mandatory refers to audit elements which are always enabled and configurable refers to audit elements which can be enabled or disabled at the discretion of the Consumer or Utility).

Dec 2007 34

Security: Authentication (Registration)

1. HAN Device shall support mutual authentication.2. HAN Device shall authenticate the source of all control signals.3. HAN Device shall provide a mechanism which allows for multiple and configurable authentication

materials (e.g., device ID, device type, key, serial key, utility ID, and device configuration).4. HAN Device shall be configured with utility-approved or -provided authentication materials (e.g.,

certificate, key).5. HAN Device shall not send authentication materials over the network in an insecure fashion (e.g., do

not transmit passwords or keys in the clear).6. HAN Device shall be compatible with a utility-defined registration process.7. HAN Device shall provide a means to update (i.e., change, reconstitute, rollover) authentication

materials.8. HAN Device shall allow registration revocation for connected HAN Devices.9. HAN Device shall support a configurable registration and expiration period (e.g., registration timeout,

registration persistence).10. HAN Device shall use security services (i.e., cryptographic services) which are either FIPS-approved

or NIST-recommended.11. HAN Device shall support a registration method that employs cryptographic operations (e.g., digital

signatures).12. HAN Device shall provide an authentication mechanism which proxies for the AMI System (e.g.,

negotiates on behalf of the utility).13. HAN Device shall provide notification to the Installer of the registration status. Status conveyed shall

be either: registered/not registered.

Dec 2007 35

Performance

1. HAN Device shall supply functionality that maintains communications availability to the AMI Gateway.

2. HAN Device shall supply functionality that maintains application availability to the AMI System (e.g., software/hardware application watchdog).

3. After loss of power, HAN Device shall return to its post-configuration state (i.e., shall persist communication and registration configurations).

4. HAN Device shall supply adequate computational performance (i.e., Device shall not hamper overall operational state of the HAN)

5. HAN Device shall supply adequate communications performance (e.g., bandwidth and throughput).

6. HAN Device shall supply accurate time keeping and counter functions. 7. HAN Device shall not act on expired signals (e.g., message validity duration or

sequence). 8. HAN Device shall provide configurable communications such that system is scalable

(e.g., heartbeat and request frequency). 9. HAN Device with battery power shall function for a minimum of 1 year.10. HAN Device shall supply a local software upgrade function (i.e., firmware upgrade).

11. HAN Device shall supply a remote software upgrade function (i.e., firmware upgrade).

12. HAN Device shall meet the quality, interoperability, and testing (i.e., certification) requirements of its respective technology platform body.

Dec 2007 36

OM&L: Manufacturing

1. Prior to installation (e.g., factory, depot), a HAN Device shall support placement of commissioning data (e.g., pre-placed network key).

2. Prior to installation (e.g., factory, depot), a HAN Device shall support placement of registration data (e.g., pre-placed registration key).

3. HAN device shall support pre-placed methods or materials that support commissioning and registration by multiple utilities (does not imply simultaneous Utility registration).

4. HAN Device shall support pre-placement of application-specific configurations (e.g., cost, consumption, environmental impact, configurable time/rate intervals).

5. HAN Device shall have and display appropriate certification (e.g., UL, ANSI, and FCC) on its packaging and body.

6. HAN Device shall have and display appropriate commissioning and registration information on its packaging and body (e.g., serial number, registration code).

7. HAN Device shall display Utility compatibility guidance to verify that a HAN Device is compatible with a particular AMI system.

8. HAN Device shall display its HAN network technology compatibility on its outside packaging.

9. HAN Device shall display UtilityAMI compliance.10. HAN Device shall display Enhanced UtilityAMI compliance. 11. The HAN device shall display, on its packaging, any secondary device requirements

(e.g., required EMS, bridge device).12. HAN Device shall be manufactured to support multiple distribution channels (e.g., retail,

direct Utility).

Dec 2007 37

OM&L: Installation

1. HAN Device Manufacturer shall include installation documentation, which includes instructions for installation (e.g., placement), commissioning, and registration, including any external dependencies.

2. HAN Device Manufacturer shall include a HAN Device user’s manual in the Device packaging.

3. HAN Device Manufacturer shall include Manufacturer contact information in the Device packaging.

4. HAN Device Manufacturer shall supply technical support services (e.g., help desk, web site).

Dec 2007 38

OM&L: Maintenance

1. HAN Device shall have a self-check (initialization) function, which notifies the Installer that the HAN Device is functioning properly.

2. HAN Device shall log all AMI System-to-HAN System communications.3. When the HAN Device is rebooted, HAN device shall reset to its configured

(i.e., post-installation commissioning and registration) state and shall reestablish communication with the AMI Gateway.

4. HAN Device shall have a user-operable testing function that is equivalent to the self-testing function.

5. HAN Device shall supply a maintenance port for field diagnostics.6. HAN Device shall simulate Utility events for diagnostic purposes.7. HAN Device shall supply network management functions for diagnostic

purposes.8. For battery-powered devices, HAN Device shall communicate low battery state

to the AMI System. 9. HAN Device Manufacturer shall supply and support a flaw remediation

process.10.HAN Device shall support a communications feedback mechanism (i.e., ping).

Dec 2007 39

OpenHAN Next Steps

Requirement working group meetings Device Mappings Comments resolution Documentation and specification production

OpenHAN specification ratification (version 1.0) Continue technology outreach OpenHAN/UtilityAMI next steps

True interoperability CIMs