erich w. gunther utilityami chairman/facilitator chairman/cto – enernex corporation...

Erich W. GuntherUtilityAMI Chairman/Facilitator

Chairman/CTO – EnerNex [email protected]

Utility Industry AMI

Requirements Development

mailto:[email protected]

http://sharepoint.ucausersgroup.org/DistribuTECH2007/default.aspx?InstanceID=1

Agenda

Introductions – Membership - Overview of organization within the UCAIug

Review scope, work plan, accomplishments, and what remains to be done – new member orientation

Task force reports AMI-Enterprise – Wayne Longcore OpenHAN – Erich Gunther AMI-SEC – Darren Highfill

Liaison reports UtiliSec / ASAP – Darren Highfill OpenAMI – Craig Rodine or designate IEEE PES IGCC – Erich Gunther / Doug Houseman

Discussion of new task force(s) and activities Marketing decks AMI-Network – only remaining task - looking for a chairman Information exchange and data repositories Other AMI application requirements needs

Other business, Next Meetings (GridWeek, Grid Interop) Adjourn – followed by OpenHAN TF and HAN SRS Overview

Join the UCAIug at: http://www.ucaiug.org/Pages/join.aspx

Get web site user ID at: http://osgug.ucaiug.org/default.aspx

Join mailing lists at: http://listserv.enernex.com/archives/index.html

List Subscribers as of August 21, 2008 AMI Enterprise Task Force (61 subscribers) AMI Security (127 subscribers) UtilityAMI Guests (75 subscribers) UtilityAMI HAN TF (152 subscribers) UtilityAMI Members (90 subscribers)

Membership

UCAIug Organization

OpenDR => OpenSG

UtilityAMI WG OpenAMI WG

Requests for specific technologydevelopment and transfer of use cases

for ongoing support and evolution

OpenHAN TF AMI-Enterprise TF

OpenSGSubcommittee

UtiliSec WG

AMI-Sec TF

OpenSG Organization

UtilityAMIDefinition, Mission and Goal

UtilityAMI is …A forum to define serviceability, security and interoperability guidelines for advanced metering infrastructure (AMI) and demand responsive infrastructure (DRI) from a utility / energy service provider perspective.


UtilityAMI will develop high level policy statements that can be used to facilitate efficient requirements and specification development using a common language that minimizes confusion and misunderstanding between utilities and vendors. UtilityAMI will also coordinate with other industry groups as required to efficiently carry out its mission.


UtilityAMI has a goal to utilize the UtilityAMI work products to influence the vendor community to produce products and services that utilities need to support their AMI and DRI initiatives.

UtilityAMI Tasks

1. Glossary and Common Language Frameworka) A universal AMI glossary of terms and definitionsb) A framework for technology capability evaluationc) A common, minimum requirements definition document

2. Modular Meter Interface – Transferred to OpenAMIPolicy for modular communication interfaces in meters

3. Security – AMI-SEC Task Force (under UtiliSEC WG)Security issues and their relationship to business needs

4. Consumer Interface – OpenHAN Task ForcePolicy for Customer Portal interface to customer end user appliances

5. AMI Network Interface – AMI-Network Task Force Policy for AMI network to MDMD/head end & HAN interfacing

6. Back Office Interface – AMI-Enterprise Task ForcePolicy for MDMS to enterprise back office system connectivity

7. General Issues Forum – Information Exchange

Common Requirements

A short, easily reviewable summary of what UtilityAMI members consider important for an Advanced Metering Infrastructure.

The currently foreseeable requirements for AMI systems.

AMI vendors should consider taking the information in this document into account when designing or developing AMI Systems or components

Each utility will be making its own independent decision on infrastructure and technology; consequently specific requirements will vary from utility to utility.

Document intended to provide to vendors some general guidelines as to currently desired AMI system functionality.

Ratified Aug 4, 2006 10 YES votes out of

10 voting – unanimous!

The utilities voting represent more than 20 million meters in North America and nearly 60 million meters worldwide.

1. American Electric Power (AEP)

2. Con Edison3. Duke Energy4. Electric Power Research

Institute (EPRI)5. Electricitie de France (EDF)6. First Energy7. Hawaiian Electric Company

(HECO)8. Keyspan Energy9. Sempra Energy (SDG&E)10.Southern California Edison

(SCE)

UtilityAMI Requirements DocumentRatification Vote Results

The Requirements

1) Standard Communication Board Interface

2) Standard Data Model3) Security4) Two-Way

Communications5) Remote Download6) Time-of-Use

Metering7) Bi-Directional and

Net Metering8) Long-Term Data

Storage9) Remote Disconnect

10) Network Management11) Self-healing Network12) Home Area Network

Gateway13) Multiple Clients14) Power Quality

Measurement15) Tamper and Theft

Detection16) Outage Detection17) Scalability18) Self locating

UtilityAMI Requirements – Page 1

Requirement Description Benefits Expected Features

Standard Comms Board Interface

A recognized open standard for the interface between a meter and its comm unications board.

The ability to mix and match communications protocols and meters and prevent being locked into a single vendors’ solution.

Physical and environmental specsElectrical specsProtocol specsCompatibility with existing form factorsAutomatic identification of comms board to meter and network

Standard Data Model

A recognized open standard for the data to be exchanged between meters and the clients of metering data.

The ability to use multiple vendors’ equipment in the same system without the cost of specialized adapters and gateways.

Usable with multiple protocolsUsable over multiple mediaClear requirements for enforcing interoperabilityGuidelines for extension

Security Protection from impersonation, modification, replay, man-in-the-middle and eavesdropping attacks throughout the whole metering infrastructure using open standards.

The ability to protect customers’ personal information in accordance with all applicable legal and regulatory requirements, including, without limitation, private usage information and billing data and prevent unauthorized actions.

EncryptionAuthenticationCredential ManagementIntrusion DetectionLogging and auditing of all changes to data and configurationApplied in all parts of the networkApplied to meter maintenance port

Two-Way Communications

The ability to reliably send data to the customer site and from the customer site over the same network.

The ability to receive confirmation that key commands such as curtailment requests, remote disconnects and meter program changes have been received and will be obeyed.

Open standard protocolsBandwidth sufficient for remote downloadEasily extendedSecureDoes not interfere with other networksOn-demand reads with the ability to get consumption, load and voltage promptly (i.e. while on the phone with a customer).



Remote Download The ability to remotely update the metering settings, configuration, security credentials and firmware of all devices in the AMI System.

The ability to correct defects, enable new features and applications, change recording and reporting intervals, refresh security, and optimize network operation without the cost of sending personnel to the customer site.

Version controlMinimal impact on operationSecureAuditable

Time-of-Use Metering

The meter can record what usage occurs within predefined intervals during the day.

Permits utilities to provide customers with information about their own usage and to implement advanced tariffs proposed by regulators.

Remotely programmable down to 5 minute intervalsRemotely programmable number of rates and billing periodsTime synchronization to within 1.5 minutes across multiple time zones.Time and date stamping of all measurements and logs.

Bi-Directional and Net Metering

The meter can record energy flow in either direction and calculate net usage.

Permits utilities to monitor and control distributed generation.

Delivered and received energy consumptionDemandInterval Data

Long-Term Data Storage

Storage of all data within the meter for at least 45 days, a minimum of two channels

Permits the network to accurately recover data after major failures.

Expandable memory in meterLonger-term storage (60 days) in concentratorsConcentrators only store data - may validate, but do not estimate



Remote Disconnect

The ability to disconnect or reconnect a customer’s electrical service remotely. This capability may not be deployed to all meters in the AMI, but the AMI must permit it to be deployed at any customer site.

Cost savings from quicker switchover of customers and from not having to send personnel to site. Improves safety for field personnel when disconnect is for lack of payment. Forced load curtailment when disconnected.

Integrated in meterSwitch position on displayMeter transmits confirmation of commands

Network Management

The ability to remotely diagnose meters and network components, and to monitor and control the status of the AMI communications network.

Cost savings from not having to dispatch crews to diagnose problems and from earlier discovery of problems. Increase in overall availability of the network for more accurate billing, demand response, and reliability purposes.

Remote self-testsStatistics gatheringTrouble alarms sent spontaneously when necessaryRemote link enable/disableSignal strength monitoringPeriodic gathering of event logsAuditing of time synchronizationDetailed daily reports on the status of the network and changes to its configuration.

Self-healing Network

The ability of the network to detect and repair network problems automatically.

Increase in overall availability of the network for more accurate billing, demand response, and power system reliability purposes.

Redundant signal pathsSwitchover algorithmsTraffic balancingData and configuration are not lost over power failuresGreater than 98% of meters successfully respond to each read



Home Area Network Gateway

The AMI System acts as a communications gateway to devices at the customer site.

Permits applications such as remote load control, monitoring and control of distributed generation, in-home display of customer usage, reading of non-energy meters, and integration with building management systems.

Open standard protocolCustomers can buy own equipmentSecureAbility to read non-energy meters

Multiple Clients The AMI System can permit multiple authorized clients within the utility and external to the utility to access the metering data.

Enables business cases for prepayment, flexible billing, online usage display, third-party aggregators, reading of other utilities’ meters, real-time market operations, and other flexible means of providing service.

On-demand, off-cycle polling Individual addressing of metersAggregation of meters into arbitrary groupsSecurity, especially authentication and authorization checking of users

Power Quality Measurement

Measurement and reporting of power quality information by the customer meter.

Efficiency and optimization of the distribution network using highly accurate data supplied by the AMI System.

Voltage min/max/profileTotal Harmonic DistortionSags/Swells/InterruptionsHarmonicsPhase Voltage RMSClose to real-time monitoring capability

Tamper and Theft Detection

The AMI System can detect and report tampering with the meter case or theft of energy.

Recovery of lost energy, repair and replacement cost reduction, cooperation with law enforcement.

Inversion detectionRemoval detectionInactivity detectionBlink counts



Outage Detection The AMI System can detect and report failures of meters due to power outages.

Faster response and recovery from outages.

Reports of outage Reports of restoration and the interval of outageStandardized open protocol interface to outage management systemsPer phase outage detection

Scaleability The growth of the AMI System is not limited by the constraints of any particular component.

Permits capital costs to be recovered and enables growth to be incremental rather than requiring large-scale component replacements.

ModularityDistributed (non-hierarchical) processingAutomatic detection of new additionsConfigurable resource limitsOpen standard interfaces

Self locating The ability to use GPS, signal strength or triangulation to geographically locate the meter

In large utilities, meters may be installed but not recorded into the system. This requirement allows the utility to locate every meter either geographically or within a short distance of a geographically known device, such as a radio tower or transformer.

Report latitude and longitude or nearest known communication d.

Promotes open standards-based HANs that are interoperable

Provides the vendor community with a common set of principles and requirements around which to build products

Ensures reliable and sustainable HAN platforms

Supports various energy policies in a variety of states, provinces, and countries

Empowers citizens with the information they need to make decisions on their energy use by enabling the vision of a home energy ecosystem

UtilityAMI 2008 HAN SRS

HAN SRS Ratification Vote Unanimous – Mar 7, 2008

AEP SCE SDG&E PG&E Detroit Edison FPL

BC Hydro Entergy Consumers Energy CenterPoint

Energy Oncor EDF

Endorsing Utilities:

Duke EnergyReliant Energy

Agenda








Liaison reports UtiliSec / ASAP – Darren Highfill OpenAMI – Craig Rodine or designate IEEE PES IGCC – Erich Gunther / Doug

Houseman

Task Force and Liaison Reports

How does the membership want to use the UtilityAMI AMI Requirements, HAN SRS and future work products?

What collateral is required? PowerPoint presentations for various audiences

Internal for executive audience – business value Internal for technical teams External for industry / conferences

White papers Who can/should produce? Value of press releases

Marketing Collateral

What are the devices and well defined points of interoperability within the field area network (FAN)?

What are the benefits of interoperability between FAN components to utilities

How do we develop requirements for them?

Network management interfaces Monitor performance Standardize configuration and upgrades?

AMI-Network TF Proposal

Task 7 in our charter Wikipedia like area for:

Glossary – we have one – needs update

AMI Project descriptions and status Repository for:

Use cases Business case tools and templates Presentations

Information Exchange

For which application areas not presently covered do you need common requirements for the purpose of influencing the AMI vendor community?

Other Application Requirements

Informative, Tech Transfer Venues GridWeek – Mon, Sep 22 – D.C. GridInterop – Wed, Nov 12 - Atlanta

Formal, Face-to-Face Meetings Oct 21-23 – Knoxville @ EnerNex Where/when next – offer to host? Somewhere

warm. Reference point - DistribuTech – Feb 3-5 – San Diego

Web Conferences AMI-SEC - ongoing What others … needs based

Other Business, Next Meetings

Agenda







OpenHAN TF Agenda

Review scope, work plan, accomplishments Maintenance, Marketing and Support

Document maintenance Marketing decks Conformance Process

Vote to approve Discuss using UCAIug conformance committee for

ongoing activity Discussion / Vote to put TF on hiatus – job done In depth presentation on the UtilityAMI 2008

HAN SRS Adjourn

OpenHAN Task Force

UtilityAMI established the OpenHAN Task Force to develop what is now known as the UtilityAMI 2008 Home Area Network System Requirements Specification (UtilityAMI 2008 HAN SRS).

Collaborative effort of more than ten investor-owned North American utilities serving more than 28 million electric and gas customers in 17 states and provinces

OpenHAN TF Deliverables

Use CasesRF reach scenarios

High rise scenarioUser scenarios

Customer moving from one utility to another?

Common RequirementsTo give vendors guidanceFor other organizations to develop detailsDerivative work from UtilityAMI requirements

Overarching Framework / Architecture

HAN SRS Ratification Vote Unanimous – Mar 7, 2008

AEP SCE SDG&E PG&E Detroit Edison FPL

BC Hydro Entergy Consumers Energy CenterPoint Energy Oncor EDF

Endorsing Utilities:

Duke EnergyReliant Energy



Vote to approve Discuss using UCAIug conformance committee for ongoing

activity

Discussion / Vote to put TF on hiatus – job done In depth presentation on the UtilityAMI 2008 HAN SRS

Too many members don’t really know what’s in there Adjourn

OpenHAN TF Agenda

Maintenance, Marketing and Support

Maintenance – Transfer to parent WGCurrent draft 1.04 fixes typos, grammar,

adds endorsersThe WG chair will handle further editorial

fixes as they ariseThe WG chair will consult the membership if

more significant issues need attention

Marketing – Transfer to UCAIugSupport – Usage, conformance

UtilityAMI HAN SRS Conformance - Purpose

Increased attention, interest, and product availability from the applying vendor / technology alliance membership

Increased attention, interest, and motivation from other vendors and technology alliances to the SRS and UtilityAMI goals

Easier vetting of technologies for utilities looking to procure and implement HAN Devices and systems

Easier certification of HAN Devices by motivating technology alliances to include HAN SRS compliance as part of their standard product certification process

UtilityAMI HAN SRS Conformance

Concept – good housekeeping seal of approval model

Final draft has been available for review since last conference call as well as distributed to the email list

Vote to approve or table



Vote to approve Discuss using UCAIug conformance committee for ongoing

activity

Discussion / Vote to put TF on hiatus – job done In depth presentation on the UtilityAMI 2008 HAN SRS

Too many members don’t really know what’s in there Adjourn

OpenHAN TF Agenda

Break

Break followed by in depth presentation of the UtilityAMI 2008 HAN SRS

UtilityAMI 2008 HAN SRS - Purpose

Promotes open standards-based HANs that are interoperable

Provides the vendor community with a common set of principles and requirements around which to build products

Ensures reliable and sustainable HAN platforms

Supports various energy policies in a variety of states, provinces, and countries

Empowers citizens with the information they need to make decisions on their energy use by enabling the vision of a home energy ecosystem

UtilityAMI 2008 HAN SRS - Audience

Utilities considering deploying AMI systems with a HAN

Vendors that make AMI systems for Utilities Vendors that make consumer products like

communicating thermostats, energy management systems, load control switches, in-home displays, smart appliances, plug-in hybrid-electric vehicles, distributed generation resources, etc.

Policy makers looking to understand how Utilities are implementing directives both within and outside of their jurisdictions

UtilityAMI 2008 HAN SRS – In Scope

The Guiding Principles, Use Cases, System Requirements, Architectural Drawings, and Logical Device Mappings for platform-independent HAN Devices that will be registered on a Utility’s secured communication channel – regardless of ownership of the devices.

Applies from the edge of the AMI System, where the Energy Services Interface (described in Section 1.4 and 2.2.1) resides, to all relevant HAN Devices in the home.

UtilityAMI 2008 HAN SRS – Out of Scope

Does not apply to Utility systems beyond the Energy Services Interface like the AMI Meter, Utility Communications Network, and Meter Data Collection and Management Systems.

Does not extend past HAN Devices in the home that do not reside on a Utility-secured communications channel.

Examples of HAN Devices not covered in the scope of this specification are home automation, home health monitoring, and security system products.

UtilityAMI 2008 HAN SRS - Use

UtilityAMI members are encouraged but not required to use and include sections of this document when procuring AMI systems with HANs and or gathering information with RFIs, RFQs, RFPs, etc.

Table of Contents

Contents 1

1. Introduction .............................................................................................................7 2

1.1 Purpose........................................................................................................................................... 7 3

1.2 Scope.............................................................................................................................................. 8 4

1.3 Acronyms and Abbreviations .......................................................................................................... 9 5

1.4 Definitions ....................................................................................................................................... 9 6

1.5 External Considerations and References ..................................................................................... 14 7

1.6 Overview....................................................................................................................................... 15 8

2. Overall Description ...............................................................................................17 9

2.1 Guiding Principles......................................................................................................................... 17 10

2.2 Architectural Considerations......................................................................................................... 21 11

3. OpenHAN System Requirements .........................................................................28 12

3.1 Requirements Framework ............................................................................................................ 28 13

3.2 Requirements Assumptions.......................................................................................................... 33 14

3.3 Application Requirements............................................................................................................. 33 15

3.4 Communication Requirements ..................................................................................................... 38 16

3.5 Security Requirements ................................................................................................................. 40 17

3.6 Performance Requirements.......................................................................................................... 45 18

3.7 Operations, Maintenance, and Logistics Requirements............................................................... 46 19

4. Appendices...........................................................................................................49 20

4.1 UtilityAMI OpenHAN Task Force Use Cases ............................................................................... 49 21

4.2 UtilityAMI OpenHAN Task Force Logical Device Mappings for Utility-Registered Devices ......... 75 22

23

HAN Guiding Principles

Value Proposition

Guiding Principles

Use Cases

Platform Independent Requirements

Platform Requirements

(Technology Specific)

System Criteria

HAN Guiding Principles

1. Secure Two-way Communication Interface with the Meter

2. Supports Load Control Integration3. Direct Access to Usage Data4. Provides a Growth Platform for Future Products

Which Leverage HAN and Meter Data5. Supports Three Types of Communications: Public

Price Signaling, Consumer-Specific Signaling, and Control Signaling

6. Supports Distributed Generation and End-Use Metering

7. Consumer Owns the HAN8. Meter-to-HAN Interface Is Based on Open Standards

1. Secure Two-way Communication Interface with the Meter

Description Basic expectation that the AMI Meter has secure two-way

communication to the Energy Services Interface (ESI), regardless of where the ESI is located.

The meter contains consumer-specific energy information and is best suited to provide the HAN with near real-time access to the data.

The ESI possesses a secure two-way communication interface for HAN Devices registered with the Utility.

Rationale The two-way communications expectation defines the AMI-to-HAN

interface and creates and enables all other capabilities within the system.

This interface may carry various data types including, sensitive data, confidential data, and control data.

Appropriate levels of security must be provided for these types of communications.

Security is critical; the security implementation protects Utility and Consumer assets while enabling the next generation of applications and capabilities.

2. Supports Load Control Integration

Description Load control is the concept of load being deferrable. A load

control device has the capability to limit the duty cycle of equipment under control.

Certain devices within the consumer’s premise (e.g., PCTs, electric pumps) can be used to shed load through direct and indirect control.

Rationale A capability to interface and integrate with load control

systems enables the Utility’s value proposition, and as such, it is critical that the capability be extended to the HAN.

In addition to load control interfacing and integration, the HAN system has several consumer enabling capabilities.

These capabilities include direct access to usage data and pricing information.

This data is generated by the meter and provides additional justification for direct meter interaction.

3. Direct Access to Usage Data

Description Provides the HAN with direct access to Consumer-specific

information and enables a new class of energy services and products.

Rationale One of the main requirements for energy conservation is a

better informed Consumer. With more timely and detailed information at the hands of the

Consumer, he will be able to make better choices about energy usage and conservation.

With direct data access, the Consumer does not need to wait until the end of the month to see how changes in his usage have affected his bill.

And with energy usage profiled in smaller increments, the Consumer can see the impact of changing his energy usage patterns.

4. Provides a Growth Platform for Future Products Which Leverage HAN and Meter Data

Description A growth platform is typically a specifically named initiative selected

by a business organization to fuel their revenue and earnings growth. The HAN is an example of a strategic growth platform. Strategic growth platforms are longer term initiatives where the

initiative and results span multiple years. While AMI is the catalyst for HAN information exchange, the growth

platform is not limited to the Utility, but to any organization that wants to create devices or services for the HAN.

Rationale Beyond information delivery and basic demand response the Utility

expects the HAN to support the next generation of applications including distributed generation, Plug-in Hybrid Electric Vehicles, and other metering applications as the technology, information, and capabilities of the HAN matures.

By supporting open standards (see Principle 8), it is expected many vendors will be able to bring capabilities and innovation to bear on the HAN market.

5. Supports Three Types of Communications: Public Price Signaling, Consumer-Specific Signaling, and Control Signaling

Description To support the anticipated market growth, the system must provide various

types of communication: public price signaling, consumer-specific signaling, and control signaling.

Public pricing is the communication of material which is publicly available. Consumer-specific signaling would be signaling such as that which would

support a home energy management system. Control signaling are those signals used to support load-shedding (see

Principle 2). Rationale

Each signal type is required to support the HAN as a growth platform (see Principle 4).

Each signal type warrants individual security and privacy analysis and treatment.

As such, the Utility does not take accountability and does not provide specific handling recommendations.

Consumer-specific information signaling implies a level of privacy and additional privacy measures and methods are warranted.

Control signaling for load control and direct Utility communications is a special use of the system and as such, requires robust handling methods.

This capability expectation is based on Utility accountability for safe and secure delivery of the control data.

6. Supports Distributed Generation and End-Use Metering

Description Distributed generation systems are small-scale power generation technologies

used to provide an alternative to or an enhancement of the traditional electric power system.

End-use metering is the idea that a second meter may be installed in the premise to support distributed generation production or measurement of discreet loads.

The OpenHAN and UtilityAMI architecture does not presume use of only electric meters.

The HAN ESI may also communicate with gas and water meters and propagate their data through the HAN (e.g., to an IHD) or through the AMI network for transfer to an appropriate entity (e.g., an electric utility could gather water meter information and pass that information to the water utility).

Rationale The ability to support communication to multiple HAN Devices provides

greater value to the Consumer and Utility by facilitating automation and reducing redundancy in the systems required to capture metering information.

As more homes and business become “green” it is anticipated that the Utility will need to support distributed generation sources such as solar panels, small wind turbines, or Plug-in Hybrid Electric Vehicle or Electric Vehicles that may discharge back into the network.

Non-revenue grade metering of end-use devices can provide consumers with additional information on the energy and cost associated with end-uses such as individual circuits, appliances, or plug loads.

7. Consumer Owns the HAN

DescriptionHAN ownership should not be confused with device

ownership or communications accountability.Consumer ownership broadly defines the rights of

the Consumer.Simply stated, the Consumer owns and controls the

HAN. Rationale

The Consumer for various reasons may concede control of her HAN.

Typically, this concession is part of the normal Utility registration process for HAN Devices.

That is, for certain types of communications the Consumer may allow Utility control.

8. Meter-to-HAN Interface Is Based on Open Standards - Description

From the IEEE P1003.0 Committee:"An open system is: A system that implements

sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered applications software to be ported across a wide range of systems with minimal changes, to interoperate with other applications on local and remote systems, and to interact with users in a style which facilitates user portability.”

A key element of this definition is the term, “open specification,” which is defined as:“A public specification that is maintained by an

open, public consensus process to accommodate new technology over time and that is consistent with standards.”

8. Meter-to-HAN Interface Is Based on Open Standards - Rationale

Openness and accessibility are the keys to availability and prevalence.

It provides for a competitive market which drives down the price of Consumer goods.

Requiring vendors to use non-proprietary standards puts competitive pressure on vendors - if any single vendor offers a proprietary solution, this is usually a stepping stone to increased maintenance and support costs.

The Utilities are constrained by the relative value of the HAN and any Utility investments needed to readily adapt to changes in the technology market.

For this reason, this specification is written as platform and technology independent.

Questions on Guiding Principles?

Architecture Considerations

The architectural consideration section is not binding Provided for context Sections include:

Utility Interface Device Ownership Public Broadcast Interface

Broadcast ID (e.g., Utility ID, SSID) Current Price (e.g., $0.XX/kWhr) Relative Price (e.g., high, medium, low) Message Expiration Time (e.g., 1 – 1440 minutes) Rate Descriptor (e.g., residential, commercial, etc.) Severity of Event Description (e.g., Stage 1, 2, 3) Integrity check (e.g., CRC)

Utility Secured Interface Consumer Devices Utility Devices Cohabitation Deregulated Utilities

Four Scenarios given as examples

Interface

AMI Backhaul Network

Utility Publ

ic Broa

dcast C

hannel

(Events,

& price

signal

)

(Energy Services

Interface)

Utility Secu

red Int

eractiv

e

Interfa

ce

Early Implementation Scenario


PCTRegiste

red Cons

umer

Device

(Secured

)

Utility Publ

ic Broa

dcast C

hannel

(Events,

& price

signal

)

Meter

(Utility Services Interface)

Utility interacts with a registered (Voluntary) PCT. The Public Broadcast Channel interface is used to provide price signals and grid event messages to the Consumer’s unregistered Smart Appliance. The ESI is located in the meter under glass.

Customer Choice Scenario


Load Control

Registe

red Cons

umer

Device

(Secured

)

Utility Devi

ce

(Secured

)

Distributed Generation

Smart AppliancePlug-in Hybrid

Consum

er Devi

ce

Utility Publ

ic Broa

dcast C

hannel

(Events,

& price

signal

)

Premise Meter

(e.g., Gas)

PCT

Premise EMS

Meter

(Utility Services Interface)

External Interface

(Internet)

Consumer has placed the PCT and other devices on a third party network but chosen to register a load control device with the Utility. The Utility is also using the HAN for communications to a gas meter. The Utility Public Broadcast Channel is available but not used.

Mature System Scenario


Load ControlPCT

Plug-In Hybrid Advanced In

Home DisplayRegi

stered

Consum

er Devi

ce (Secu

red)

Utility Devi

ce

(Secured

)

Lighting Control

Smart ApplianceHealth Care

Set Top Box

Consum

er Devi

ce

Distributed

Generation

Utility Publ

ic Broa

dcast C

hannel

(Events a

nd pric

e sign

al)

Premise Meter

(e.g., Gas)

Premise

Electric Meter In Home Display

Premise EMS

Energy Services Interface

External Interface

(Internet)

Several Consumer and Utility devices, several of which are registered with the Utility. HAN Devices are accessible to the external interface/gateway (Internet). The Utility Public Broadcast Channel is available but not used.

Deregulated Scenario



Smart AppliancePlug-in Hybrid

Retail E

nergy

Provide

r Netw

ork

Utility Publ

ic Broa

dcast C

hannel

(Events a

nd pric

e sign

al)

PCT

Distribution to

Retail Gateway


External Interface

(Internet)

All devices sit on the third party network. The electric distribution company provides information through its Energy Services Interface. The distribution company’s accountability boundary ends at the Retail Gateway device. The Utility Public Broadcast Channel is available but not used.

Section 3 – The Requirements

In designing the system, the OpenHAN Core Development team considered a number of criteria. They are:HAN ApplicationsCommunicationsSecurityPerformanceOperations-Maintenance-Logistics

Requirements Overview

Requirements are platform independent Requirement are to products applied via device

mappings (Appendix) Special class of requirements for an AMI

gateway (See Mappings) Two types of compliance

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

Vendor/product – compliant with device mapping requirements

Criteria - HAN Applications

Any application that is enabled through the HAN will have one or more of the following characteristics:ControlMeasurement and MonitorProcessingHuman-Machine Interface (HMI)

HAN Applications - Control

Control applications respond to control signals.

The simplest control application is direct control, which turns loads on or off.

Control applications can also cycle, which means they turn the load on and off at configurable time intervals.

More sophisticated control applications can limit the load of an appliance based on configurable thresholds.

HAN Applications – Measurement and Monitor

Provide internal data and status. Includes distributed generation functionality where

local energy input and output is measured and monitored.

End-use metering functionality to measure and monitor device-specific energy consumption or production.

A consumer Plug-in Hybrid-Electric Vehicle (PHEV), for example, can have end-use metering functionality as well as distributed generation.

Applications can be as simple as measuring and monitoring the environmental state or whether a device is on or off.

HAN Applications - Processing

Consume, process and act on external and internal data. These applications accept data from external systems and HAN

measurement and monitoring applications. Applications with processing capability are generally more

complex and costly. The following applications requiring processing:

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. based on the CO2 emission profile of a Utility’s generation portfolio)

HAN Applications - HMI

Most applications will need an HMI in order to provide local user input and/or output.

These applications are 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)

Criteria - HAN Communications

HAN Communications is one of the most challenging categories of the AMI systems.

The HAN SRS identified communications criteria for:DiscoveryCommissioningControl

HAN Communications - Discovery

Discovery of a node is simply the identification of a new node within the HAN and it generally involves the following: 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

HAN Communications - 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.

Commissioning involves the following: Identification - Uniquely identifying the deviceAuthentication - Validation of the device (e.g., the

network key)Configuration - Establishing device parameters

(e.g., network ID, initial path, bindings)

HAN Communications - Control

Control of a node is enabled by the platform specific technology and it involves: Organization - Communication paths (e.g.,

route)Optimization - Path selectionMitigation - Ability to adapt in response to

interference or range constraints through detection and analysis of environmental conditions

Criteria - HAN Security

Introduction of a communications technology for the home requires enhanced security to protect the overall AMI system.

The UtilityAMI AMI Security Task Force addresses the security requirements of the AMI system in greater detail.

The HAN SRS addresses specific security criteria that pertain to the ESI’s Utility-Secured Interactive Interface.

The security categories addressed are:Access Control and ConfidentialityRegistration and Authentication IntegrityAccountability

HAN Security – Access Controls and Confidentiality

Levels of data protection based on data type. All data will have some level of access control,

but there are various requirements associated with 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, other premise metering data)

HAN Security – Registration and Authentication

Crucial to verify and validate HAN participation. Once a node is registered, it is trusted in the network. Registration and authentication involves the following:

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 – Correlates an account (e.g., Consumer) with a HAN Device, application, or program (e.g., demand response programs, peak time rebate, etc.)

Authorization – Governs rights granted to the applications Revocation – Removes an established node, correlation, or

authorization

HAN Security - Integrity

Preserves the HAN operating environment through: 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)

HAN Security - Accountability

Allows for monitoring malicious activities through: Audit – Application log detected

compromise attemptsNon-repudiation – Applications and

application operators are responsible for actions (e.g., can not deny receipt or response)

Criteria - HAN Performance

Ensures that applications or other factors do not limit the performance of the system.

Platform-independence dictates that these criteria are higher level than the others found in this document.

Less detailed than others for the same reason that, depending on Utilities’ technology selection, their performance requirements will differ.

Performance of the system is usually dependent on the following: 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

Criteria – Operations, Maintenance and Logistics

Addresses the challenges around deploying HAN Devices in a new market segment.

The goal is to keep maintenance to a minimum and make the operation of the system as easy as possible while not compromising security and performance.

Activities involved in reaching this goal: 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

Applications

DirectControl

Cycling Control

Limiting Control


Submetering

EnvironmentState

Device State

EnergyCost

Energy Production

Energy Optimiza-

tion

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

Initializa-tion

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

Requirements Assumptions

1. Consumer owns his Premise and Utilities are granted access rights by the consumer or by regulatory authority.

2. The Utilities expect vendor differentiation and innovation in the marketplace.

3. Devices do not prioritize commands (e.g., last command overrides previous).

4. Assume orderly shutdown of operations (e.g., could be delayed until current process completes).

5. Does not presume source of message (i.e., Utility or certified premise EMS).

6. Does not cover the consequences or incentives associated with participation or compliance (e.g., Overriding mandatory control signals).

7. Certified premise EMS can proxy as the Utility.8. EMS devices are viewed as aggregating functions within the

system.9. EMS can aggregate data from multiple sources.

Requirements Assumptions – Con’t

10. Rate information can pass from the Energy Services Interface to the Energy Cost application.

11. Energy Cost applications are not intended to reconcile costs displayed on HAN Devices with bills generated by a Utility billing system. There are other elements associated with billing and revenue-grade metering that are outside the scope of these requirements (e.g., revenue-grade certification, rate recovery).

12. The Energy Cost applications are likely components of an Energy Management System.

13. Alarm features would likely be part of separate Energy Optimization applications (e.g., signal an alarm when the accumulated cost for the month is greater than $100).

14. For authentications to be considered secure they must not be able to be reversed with modern computing technology in the amount of time for which they are valid.

Requirements Assumptions – Con’t

All requirements comprise a “shall…” statement that clearly outlines the requirement and minimizes the potential for confusion.

The requirements listed are not prioritized by criticality or sophistication and include some fairly advanced functional capabilities that may be beyond the current state of the market. This is intentional.

Readers should refer to Appendix 4.2 – Logical Device Mappings for Utility-Registered Devices – for guidance on which requirements are mandatory for logical devices to be considered UtilityAMI compliant.

Requirements Example - Control

Context:Applications that respond to control commands from the utility orauthorized third parties. Commands typically tell a device to turn ON/OFF atconfigurable time intervals or thresholds or enter into an energy saving mode.

Requirements: App.Control.1 HAN Device shall accept control signals from the utility. App.Control.2 HAN Device shall respond to requests to cease operational

state (e.g., open contact). App.Control.3 HAN Device shall respond to requests to resume

operational state (e.g., close contact). App.Control.4 HAN Device shall acknowledge receipt of control signal. App.Control.5 HAN Device shall acknowledge execution of control

request. App.Control.6 HAN Device shall acknowledge execution failure of request

(i.e., exceptions). App.Control.7 HAN Device shall signal any consumer-initiated overrides.

Questions on Requirements?

Open document if necessary and look at individual requirements sections.

Appendices

Use CasesLoad and Energy ManagementEnergy Management SystemUser InformationEnergy Storage and GenerationFixed HAN Devices with Metering CapabilityMobile HAN Device with Metering CapabilitySystem Configuration and Management

Logical Device Mappings

Logical Device Mappings

Tool for applying the specification Device mappings are logical Actual Product offerings may include several logical devices Legend: Basic (B), Enhanced (E), Not Applicable (NA), Optional (O) Optional Requirements – suggestion to vendor to examine capability Logical Devices include:

• Energy Services Interface• PCT• Display• EMS• Load Control• HAN Electric Meter• HAN Meter (non-electric)• Smart Appliance

Device Mapping Example

Requ. IDOpenHAN System

Requirements


PCT Display EMSLoad

Control

HAN Electric Meter

HAN Meter (non-

electric)

Smart Applianc

e

App.Control.1HAN Device shall accept control signals from the Utility. NA B B B B B B B

App.Control.2

HAN Device shall respond to requests to cease operational state (e.g., open contact). NA B NA B B NA NA E

App.Control.3

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

App.Control.4HAN Device shall acknowledge receipt of control signal. NA B NA B B NA NA E

App.Control.5HAN Device shall acknowledge execution of control request. NA B NA B E NA NA O

App.Control.6

HAN Device shall acknowledge execution failure of request (i.e., exceptions). NA E NA E E NA NA O

App.Control.7HAN Device shall signal any consumer-initiated overrides. NA B NA B E NA NA O

App.Control.8

HAN Device shall respond to request to cease operation state at a specific time. NA B NA B E NA NA O

Question on Mapping?

Open document if necessary and look at individual sections.

erich w. gunther utilityami chairman/facilitator chairman/cto – enernex corporation...

Documents