Transcript UtilityAMI OpenHAN TF Requirements Working Group Specification Briefing December 2007 Dec 2007 Introduction  Purpose:        Information sharing (level setting) Validate approach Drive technology implementations Establish participation and responsibility Describes utility’s.

UtilityAMI OpenHAN TF
Requirements Working Group
Specification Briefing
December 2007
Dec 2007
1
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:






Dec 2007
Introduction
Documentation process
Guiding principles
Use Cases
System Criteria
Next Steps (Requirements Composition)
2
Utility HAN Framework




Dec 2007
s
ria tic
ite teris
r
C ac
t
tem har
en
s
nd
Sy a l C
e
n
ep ts
tio
Ind men
nc
u
m
F
r
re
tfo qui
Pla Re
t
ian
pl
T
e
Gr
Sy Con chn
idW
nta ne ica
cti cti l
ise
c | vit
Inte
Ne y
rop
tw
or
era
k
bili
ty
Fra
me
wo
rk
s
m
Co
Co Info
nte rm
xt atio
|S
em nal
an
tic
N
Or
Ob Eco gan
jec no izat
tiv mic ion
es
a
| P | Pol l
ro icy
ce
du
res
lue n
Va sitio
o
op
Pr
&
ion g
s
i
V idin les
Gu ncip
i
Pr
s
se
Ca
e
Us
HA
en
Op

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
ts
en )
m
e
ific
ir
qu pec
y
e
S
R
rch
m ogy
a
r
r
o
l
ie
o
tf
Pla echn
le H
c
T
y
(
c
ife
NL
A
H
3
Utility Specific Value Proposition
Examples: PUC, SOX, NERC, etc.
Business
Continuity Needs
Assessment
Regulatory
Compliance
Analysis
Common Principles
Program Needs
Common Purpose Common Vision
Industry Enablers
OpenHAN Documentation Process
Business Needs
Documentation Process (Ratified)
ied
Ratif
CA IOU
Validation
Use Cases
System Criteria
ied
Ratif
ied
Ratif
OpenHAN Vetting
and Refinement
Compliance
Validation
Platform Independent
Requirements and Architecture
OpenHAN
Assessment
Technology Platforms and Alliances
Dec 2007
4
HAN Guiding Principles
Value
Proposition
Guiding
Principles
Use Cases
System Criteria
Platform Independent
Requirements
Platform Requirements
(Technology Specific)
Dec 2007
5
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
6
HAN Use Cases
Value
Proposition
Guiding
Principles
Use Cases
System Criteria
Platform Independent
Requirements
Platform Requirements
(Technology Specific)
Dec 2007
7
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
8
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




Dec 2007
Energy Management System
Energy Storage and Distribution
User Information
HAN Metering
9
Platform Independent Requirements
Value
Proposition
Guiding
Principles
Use Cases
System Criteria
Platform
Independent
Requirements
Platform Requirements
(Technology Specific)
Dec 2007
10
Requirements working group feedback
(Principles and Architecture)
Dec 2007
11
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
12
Clarify Architectural Assumptions
Dec 2007
13
Scenario 1: Inception
ity
Util
er
m
u
ns
Co
ns
atio
plic
p
A
tive
rac
e
t
n
I
PC
T
Util
ity AM
Ow I G
ne atew
da
nd ay
Op
era
ted
AM
IB
ac
kh
au
lN
etw
ork
Dec 2007
t
as
dc nal)
oa
Br e sig
c
ric
bli
Pu .g,., p
ity
e
Util nel (
an
Ch
14
Scenario 2: PCT and Gas Meter
tive
rac
Inte
y
it
Util
er
sum
n
Co
s
tion
lica
p
Ap
PC
T
Re
v
Ele enu
ctr e G
ic M ra
ete de
r
Util
ity AM
Ow I G
ne atew
da
nd ay
Op
era
ted
AM
IB
ac
kh
au
lN
etw
ork
Dec 2007
s
tion
lica
pp
A
ity
Util
t
as al)
dc
roa sign
B
e
blic ric
Pu .g,., p
ity
e
Util nel (
an
Ch
15
Scenario 3: Mature Utility HAN
ity
Util
er
m
u
ns
Co
ns
atio
plic
p
A
Ce
tive
rtif
ied
rac
e
t
P
n
H
I
Lo
ad
Co
ntr
ol
PC
T
Ad
va
nc
ed
IHD
Ce
rtif
ied
DG
yb lugrid
In
tion
ica
un
m
m
Co l
red ne
cu han
e
C
S
ity
Util R
No eve
n-e nu
lec e G
tric ra
Me de
Re
ter
ve
Ele nu
ctr e G
ic M ra
ete de
r
Util
ity AM
Ow I G
ne atew
da
nd ay
Op
era
ted
AM
IB
ac
kh
au
lN
etw
ork
Dec 2007
ns
atio
plic
p
A
ity
Util
t
as
dc nal)
oa
Br e sig
c
ric
bli
Pu .g,., p
ity
e
Util nel (
an
Ch
16
Scenario 4: Utility HAN + HA
ity
Util
er
m
u
ns
Co
ns
atio
plic
p
A
Ce
tive
rtif
ied
rac
e
t
P
n
H
I
Lo
ad
Co
ntr
ol
PC
T
Ad
va
nc
ed
IHD
Ce
rtif
ied
DG
yb lugrid
In
tion
ica
un
m
m
Co l
red ne
cu han
e
C
S
ity
Util R
No eve
n-e nu
lec e G
tric ra
Me de
Re
ter
ve
Ele nu
ctr e G
ic M ra
ete de
r
Util
ity AM
Ow I G
ne atew
da
nd ay
Op
era
ted
AM
IB
ac
kh
au
lN
etw
ork
Dec 2007
ns
atio
plic
p
A
ity
Util
(e. HA
g.,
Se Cont
t T roll
op er
Bo
x)
Sm
art
Ap
plia
nc
e
Lig
htin
gC
on
tro
l
ns
atio
plic
p
rA
me
nsu
Co
t
as
dc nal)
oa
Br e sig
c
ric
bli
Pu .g,., p
ity
e
Util nel (
an
Ch
17
Scenario 5: Utility HAN + EMS + HA
ity
Util
er
m
u
ns
Co
ns
atio
plic
p
A
Ce
tive
rtif
ied
rac
e
t
P
n
H
I
Lo
ad
Co
ntr
ol
PC
T
Ad
va
nc
ed
IHD
Ce
rtif
ied
DG
yb lugrid
In
tion
ica
un
m
m
Co l
red ne
cu han
e
C
S
ity
Util R
No eve
n-e nu
lec e G
tric ra
Me de
Re
ter
ve
Ele nu
ctr e G
ic M ra
ete de
r
Util
ity AM
Ow I G
ne atew
da
nd ay
Op
era
ted
AM
IB
ac
kh
au
lN
etw
ork
Dec 2007
ns
atio
plic
p
A
ity
Util
P Ce
Util rem rtifie
d
ity ise
A
E
Ga pplic MS
tew atio
ay
n
(e. HA
g.,
Se Cont
t T roll
op er
Bo
x)
Sm
art
Ap
plia
nc
e
Lig
htin
gC
on
tro
l
Ho
me
Se
cu
rity
Ho
me
Ca Healt
h
re
ns
atio
plic
p
rA
me
nsu
Co
t
as al)
dc
roa sign
B
e
blic ric
Pu .g,., p
ity
e
Util nel (
an
Ch
18
Scenario 6: Mature System
ity
Util
er
m
u
ns
Co
ns
atio
plic
p
A
Ce
tive
rtif
ied
rac
e
t
P
n
H
I
Lo
ad
Co
ntr
ol
PC
T
Ad
va
nc
ed
IHD
yb lugrid
In
tion
ica
un
m
m
Co l
red ne
cu han
e
C
S
ity
Util R
No eve
n-e nu
lec e G
tric ra
Me de
Re
ter
ve
Ele nu
ctr e G
ic M ra
ete de
r
Util
ity AM
Ow I G
ne atew
da
nd ay
Op
era
ted
AM
IB
ac
kh
au
lN
etw
ork
Dec 2007
Ot
h
Ga er Pr
(In tewa emis
ter
e
ne y
t)
Ce
rtif
ied
DG
ns
atio
plic
p
A
ity
Util
P Ce
Util rem rtifie
d
ity ise
A
E
Ga pplic MS
tew atio
ay
n
(e. HA
g.,
Se Cont
t T roll
op er
Bo
x)
Sm
art
Ap
plia
nc
e
Lig
htin
gC
on
tro
l
Ho
me
Se
cu
rity
Ho
me
Ca Healt
h
re
ns
atio
plic
p
rA
me
nsu
Co
t
as al)
dc
roa sign
B
e
blic ric
Pu .g,., p
ity
e
Util nel (
an
Ch
19
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
20
Level 1
HAN Requirements Organization and System Criteria
Level 3
Level 2
System*
Applications
Communications
Security
Access
Registration
Control
Confidenti- Authentication
ality
Control
Measure
Monitor
Processing
Human
Machine
Interface
Commision
Control
Direct
Control
Distributed
Generation
Energy
Cost
User
Input
Announce
Organize
Public
Cycling
Control
Submetering
User
Output
Respond
Optimize
Identify
Prioritize
Energy
Consumption
Operations
Maintenance
Logistics
Performance
Integrity
Accountability
Availability
Reliability
Maintainability
Initialization
Resistance
Audit
Scalability
Upgradeability
Quality
Private
Validation
Recovery
NonRepudaition
Utility
Correlation
Labeling
Authorization
Purchasing
Manufacture Installation
Distribute
Manage
Maintain
Precommision
Document
Alarm
Logging
Registration
config
Support
Testing
Level 4
Energy
Production
Limiting
Control
Environment
State
Device State
Energy
Optimization
Energy
Demand
Reduction
Environment
Impact
Authenticate Mitigation
Reset
Revocation
Payment
Platform Independent Requirements
Dec 2007
21
HAN Requirements Organization and Use Cases
Energy Storage and Distribution
Use Case
Load and Energy Management
Control
Depot Configuraiton
Remote Diagnostics
Installation and Provisioning
Registration
Maintenance and Troubleshooting
Applications
Communications
Security
Measure
Monitor
Processing
Human
Machine
Interface
Discovery
Commision
Control
Access
Registration
Control
Confidenti- Authentication
ality
Integrity
Operations
Maintenance
Logistics
Performance
Accountability
Availability
Reliability
Maintainability
Manufacture Installation
Distribute
Manage
Maintain
See System Criteria for Level 4 Details
Basic
Level 4
Level 3
Level 2
Submetering
User Information
Advanced
Requirements
Requirements Analysis
EMS
Dec 2007
22
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
23
Application: Control
1.
2.
3.
4.
5.
6.
7.
8.
9.
HAN Device shall accept control signals from the Utility.
HAN Device shall respond to requests to cease operational state (e.g., open contact).
HAN Device shall respond to requests to resume operational state (e.g., close contact).
HAN Device shall acknowledge receipt of control signal.
HAN Device shall acknowledge execution of control request.
HAN Device shall acknowledge execution failure of request (i.e., exceptions).
HAN Device shall signal any consumer-initiated overrides.
HAN Device shall respond to request to cease operation state at a specific time.
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, setpoints 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
24
Application: Measurement
1.
2.
3.
4.
5.
6.
HAN Device shall measure instantaneous demand (e.g., W).
HAN Device shall measure accumulated consumption (e.g., Wh).
HAN Device shall measure accumulated production (e.g., Wh).
HAN Device shall measure consumption per interval (e.g., Wh, BTU, HCF).
HAN Device shall measure production per interval (e.g., Wh).
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
25
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
26
Application: Processing
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).
1.
Dec 2007
27
Application: Processing 2
12. The application shall forecast a HAN Device’s estimated cost calculation based on userdefined 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 userdefined 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
28
Communications: Commissioning
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Dec 2007
HAN Device shall accept network configuration data which allows for private Utility networking (e.g.,
private address/ID)
HAN Device shall accept commissioning configuration data by the manufacturer (e.g., link key).
HAN Device shall accept commissioning configuration from the Installer.
When a HAN Device is triggered (e.g., Allow Join Command), HAN Device location-specific/contactspecific data shall be provided to other HAN Devices in the premise.
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.
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 preconfigured with Utility information.
HAN Device shall have the ability to accept or reject the request based on device type.
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.
HAN Device shall acknowledge successful commissioning requests (i.e., provide acknowledgement
to the requesting HAN Device).
When a HAN Device is communicating with the AMI Gateway, HAN Device shall indicate link
connectivity.
HAN Device shall provide notification to the Installer of the commissioning status. Status conveyed
shall be either: successful/unsuccessful.
HAN Device shall maintain an updated list of commissioned (i.e., connected) HAN Devices.
HAN Device shall have the ability to remove HAN Devices from the Utility HAN.
29
Communications: Control
1.
2.
3.
4.
5.
6.
7.
HAN Device shall accept network organization messages from the AMI Gateway (e.g., gateway
location, routing table, address).
HAN Device shall accept network organization messages from peer devices (e.g., hidden node).
HAN Device shall use the most reliable path to the AMI Gateway (e.g., based on signal
strength/quality).
HAN Device shall only use routes within its logical network (e.g., network ID, address scope, Utility
ID).
HAN Device shall support prioritization of traffic (e.g., queuing, scheduling, traffic shaping).
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, signalto-noise ratio).
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
30
Security: Access
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Dec 2007
HAN Device shall provide access control to Utility applications, data, and services (e.g., control data,
consumer-specific consumption data).
HAN Device shall control access to persistent Utility HAN data (data at rest).
HAN Device shall control access to transmitted Utility HAN data (data in transit).
HAN Device shall provide protection of Utility HAN data while being processed (data in processing)
(e.g., trusted processor).
HAN Device shall control access to data in accordance with a configurable Utility security policy (e.g.,
users, applications, devices, data access-read/write).
HAN Device shall provide mechanisms to enforce a policy based on least privilege (i.e., explicit
authorization).
HAN Device shall have the ability to enforce policy periods (time constraints) for security policy
elements (e.g., maintenance/firmware window).
HAN Device shall control access to data in accordance with a configurable Utility security policy (e.g.,
users, applications, devices).
HAN Device shall provide methods to query and report access control data settings.
HAN Device shall provide access control methods which prevent known attacks, including replay,
man-in-the-middle, delay, spoofing, sequence change, and deletion attacks.
HAN Device shall implement mechanisms to prevent unintended disclosure of source/originator data
to unauthorized principals.
HAN Device shall implement controls which limit access to audit information.
HAN Device shall support confidentiality and access controls that employ cryptographic operations
(e.g., digital signatures).
HAN Device shall support confidentiality and access controls that employ cryptographic keys for only
one purpose (e.g., encryption authentication, or digital signatures).
31
Security: Integrity
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
Dec 2007
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).
HAN Device shall provide a configurable HAN filtering function that filters based on allowable message types.
HAN Device shall provide a configurable HAN filtering function that filters messages based on structural integrity of
the message.
HAN Device shall provide a configurable HAN filtering function that filters based on allowable message rates.
HAN Device shall detect unauthorized modification of data during storage (e.g., check sums, hashes, software
attestations).
HAN Device shall detect unauthorized modification of data during network transit (e.g., check sums and hashes).
HAN Device shall attempt to correct unauthorized modification of data (e.g., resend).
HAN Device shall detect unauthorized modification of data attributes (e.g., modification to a message type).
HAN Device shall attempt to correct unauthorized modification of data attributes.
HAN Device shall only accept data from an authorized source (e.g., AMI Gateway, certified EMS).
HAN Device shall protect the system from malicious code (e.g., buffer overflow protection, limit executable code
exposure).
HAN Device shall detect known attacks, including replay, man-in-the-middle, delay, spoofing, sequence change,
and deletion attacks.
HAN Device shall separate security critical functionality and data from non-security critical system data.
HAN Device shall validate the source of HAN security policy.
HAN Device shall detected unauthorized modification of HAN security policy.
HAN Device shall detect unauthorized modification of audit data.
HAN Device shall validate the integrity of all software updates, including source, structure, and version.
HAN Device shall use tamper-resistant hardware (e.g., epoxy, TPM).
32
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
33
Security: Authentication (Registration)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Dec 2007
HAN Device shall support mutual authentication.
HAN Device shall authenticate the source of all control signals.
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).
HAN Device shall be configured with utility-approved or -provided authentication materials (e.g.,
certificate, key).
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).
HAN Device shall be compatible with a utility-defined registration process.
HAN Device shall provide a means to update (i.e., change, reconstitute, rollover) authentication
materials.
HAN Device shall allow registration revocation for connected HAN Devices.
HAN Device shall support a configurable registration and expiration period (e.g., registration timeout,
registration persistence).
HAN Device shall use security services (i.e., cryptographic services) which are either FIPS-approved
or NIST-recommended.
HAN Device shall support a registration method that employs cryptographic operations (e.g., digital
signatures).
HAN Device shall provide an authentication mechanism which proxies for the AMI System (e.g.,
negotiates on behalf of the utility).
HAN Device shall provide notification to the Installer of the registration status. Status conveyed shall
be either: registered/not registered.
34
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
35
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
36
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
37
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
38
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
Dec 2007
39