Erich W. Gunther, P.E. Chairman and CTO EnerNex Corporation [email protected] Chairman UtilityAMI,...

Erich W. Gunther, P.E.Chairman and CTO

EnerNex Corporation

[email protected]

ChairmanUtilityAMI, OpenHAN,

CA Title 24 PCT Reference Design Task Force

Home Area Network

Workshop

http://www.spintelligent.com/

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

• Introductions• Context Setting

• EPRI Consumer Portal Project Overview• California Influence

• Reference Design for AMI and DRI• Demand Response –Title 24 PCT

• Industry Response• OpenAMI Overview• UtilityAMI Overview

• Questions and Discussion• Break• OpenHAN – What have we been up to?• Security – Examples, Issues, Opportunities• Questions and Discussion• Adjourn - Lunch

Agenda

Questions before proceeding?

EPRI Consumer Portal Overview

Consumer Portal FAQ Copyright © EPRI 2005 – 4

Consumer Portal FAQ

• What is a Consumer Portal?

• Why are we talking about portals?

• How would a portal be used?

• What could portals do?

• Which functions of a portal are most important?

• How could portals make money?

• What could a portal look like?

• What do YOU think?


What is a Consumer Portal?

“A combination of hardware and software that enables two-way communication between energy service organizations and equipment within the consumers’ premises.”


What is a Consumer Portal?

More Possible Definitions

• A “router” that just forwards messages

• A “gateway” that translates technologies

• A “single point of access”:– From multiple organizations

– To a variety of customer premises equipment

• A “virtual device” that may be located in:– A meter

– A thermostat

– A PC

– A set-top box

– All or none of the above

• A “window” into the customer site


Why are we talking about portals?

• Frustration– Too many failed attempts

– Proprietary systems

– Unable to deploy on large enough scale

• Regulation– California, Ontario, New York, etc.

– Trying to “level the playing field”• Reduce barriers for vendors

• Make costs common to all

• Ensure common service for consumers

• Evolution– Recent events putting pressure on the grid

– Must find a way to adapt


Why are we talking about portals? The Power System is Under Pressure!

• Reliability– 2003 Northeast Blackout

– The grid is “brittle”

• Security– Terrorist attacks

– The grid is vulnerable

• Markets– Deregulation, opening of energy markets

– Unprecedented sharing of data

• Consumer Demands– Distributed generation, green energy, need for hi-quality power

– Consumers are demanding a say in the operation of the grid


Why are we talking about portals? Portals Lead to an Intelligent Power Grid

• The IntelliGrid Consortium:– A group of Utilities, vendors, researchers and governments

– Goal is a grid communications system for a “digital society”

– Has developed an architecture: www.epri-intelligrid.com

– Intended to address the pressures discussed here

– A grid that automatically predicts failures, heals, optimizes, and interacts with customers

• Where does a consumer portal fit in?– High volumes of timely, accurate information

– Gathered from millions of customer sites

– Enables more responsive simulation, modeling, optimization, prediction, and markets

http://www.epri-intelligrid.com/


How could a portal be used? A scenario.

• A “heat storm” is due tomorrow

• Energy service provider notifies consumers that a “super peak” tariff is coming

• Consumer previously told the portal how to react

• Some consumers permitted to bid into the load reduction market

Allow Load Control

Setback Cooling by 2°

Your current usage is 35.85 kW

Load control is currently in effect with a 4°F cooling setback scheduled to take effect at 3:00 PM

Your energy consumption for this billing period is 6240 kWh costing an estimated $998.40

By managing your energy you have saved an estimated $108.47 in this billing period

Set Price Response Options

A message from California Power Company: The system is operating well and no emergency load reduction requests are expected today. Tomorrows forecast is for hotter and more humid so prices will be up be up again tomorrow. We appreciate your business.

Tomorrow's forecast is hot, hazy and humid with a high of 110°

Cycle Water Heater

Reduce Lighting

Setback Cooling by 4°

California Power Company


How could a portal be used? The Response

• Portal adjusts load when the new rate hits:– Increases thermostat setting

– Turns off water heater

• User could have provided input:– Viewed the tariff change

– Adjusted settings

– Viewed $$ savings

• But not necessary!

• Portal reacts anyway.


How could a portal be used? An Emergency

• Tree contact causes transmission line fault

• Transmission lines overloaded

• ISO issues load reduction request to portals

• Each portal cuts back load drastically

• Distribution operator queries all portals in the area

• Extent of the outage becomes clearly visible

• Operator acts quickly to partially restore power


What could portals do?

A portal could have many clients:

• Residential and commercial consumers

• Energy service providers

• Independent system operators

• Distribution companies

• Other utilities

• Non-utility organizations

• Others

Each of these clients could use it differently.



Advanced Metering and Demand Response

Consumer Site

Portal

Utility

Aggregated metering data

· New tariffs· Emergency

Indications

Energy measurements

Load controls



Residential Customer Services

Portal

· Billing info· Energy usage· Energy savings· Emergency indications

· Contract terms· Trouble indications· Choice of ESP

· Trouble Reports· Choice of ESP· Response settings

Utilities

`

Consumer



Advanced Customer Services

• Integrate with local Energy Management System

• Optimize energy use

• Compute energy efficiency

• Control distributed generation

• Coordinate load profiles between buildings

• Submit bids to energy markets

Portal

· Load bids· Generation bids· Power quality

reports

Response Market

Generation Market

Utility

Energy measurements

Pricing info

EMS



Customer Management

• Remotely connect or disconnect customers

• Detect tampering

• Detect theft of energy

• Limit maximum load in response to billing irregularity

`

AccountManager

Portal

· Connect· Disconnect· Set Limits

Alerts

· Tamper indications· Energy measurements

Consumer Site



Widespread Distribution of Data

• Provide large volumes of accurate data for marketing, simulation, modeling, and predictive maintenance

• Aggregate data from multiple types of utilities

• Stagger load pickup in “black start” emergencies

Database

DetailedEnergy

Measurements

Markets

Research

Utility Operations Portals at Consumer Sites



Advanced Distribution Operations

• Detect and isolate outages more quickly

• Shed load with finer control

• Use demand response customers as a “fast reserve”

• Monitor and optimize power quality more accurately

• Monitor and control distributed generation

• Minimize system losses

Portal

· Switch generation· Shed load· Transfer load

DistributionOperator

· PQ data· Volt/VAR data· Trouble reports

Measurements

· Load controls· Generation

controls

EMS


Portal

Consumer Site

· Security alerts· Medical monitoring· Environmental info· Others

· Entertainment· Efficiency data· Others

AdvancedServices


Non-Energy Applications

Also:

• Weather forecasting

• Flooding and freezing alerts

• Air quality

• Optimize building heating and lighting


Which portal functions are most important?

• Feedback from IntelliGrid Consortium members

0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50

Energy Efficiency Services

Outage, Tamper and Theft Detection

Automatic Meter Reading

Customer Connect/Disconnect/Set Limit

Demand Response and Load Shifting

Power Quality Monitoring

Customer Change of Energy Supplier

Metering Data for Market Settlement

Advanced Pricing and Real Time Pricing

Integration of Distributed Generation

Integration with Customer EMS

Aggregation of Multi-Energy data

Non-Energy Services

Average Rated Importance (1-5)


How Could Portals Make Money?

Benefits:

• Increased system efficiency, stability, and power quality

• Cumulative savings from demand response

• Avoided costs of incremental capital investment

• Recovered costs:– Theft detection– Fewer outages

• New income:– New value-added services– Participation in markets with better

data

Barriers:

• Cost of equipment– Portal itself (unless embedded in

other devices)– Peripherals, e.g. meters, thermostats,

EMSs

• Cost of deploying networks– To the consumer site– Within the consumer site

• Cost of operation– Signing up customers – Technical support– Billing infrastructure


How could portals make money?

EPRI Study - 2004

• 5-20 year assessment of California market

• 15% discount rate assumed

• $15B benefit to society AFTER investors have earned 15%!

-$3,000 -$2,000 -$1,000 $0 $1,000 $2,000 $3,000 $4,000 $5,000 $6,000 $7,000

Consumer Portal Investment

Operating and Maintenance Costs

Energy Cost Savings due to DemandResponse

Avoided Costs

System Benefits

Reliability and PQ Benefits

Energy Efficiency and Energy Services

Net Present Value of Cost/Benefit (x$1000)

NPV of Costs/Benefits = $14.7B


How could portals make money?

Lessons Learned – from dozens of past attempts

• The technology exists.– No breakthroughs are necessary

• Make it simple.– Customer must be able to not participate

• Standardize.– Don’t try to “lock in” customers to proprietary systems– Achieve economies of scale and reduce costs

• Share the infrastructure.– Use portal-like services from other industries

• Build an architecture.– Integrate the portal with the whole energy system– Don’t create “islands of automation”

• Don’t strand assets.– Make it easy and inexpensive to upgrade– The best applications may be yet to come

• Share the benefits.– Distribute the “societal benefits” to everyone


What could a portal look like?

• A consumer portal is an idea, not a particular device!

• IntelliGrid is developing a reference design– A standard “virtual appearance” for a portal

– A clearly defined set of interfaces

– May be incorporated into a variety of devices

– May be distributed among several devices

• The physical device(s) may vary, but the virtual device must be standardized to ensure

– Interoperability between vendors

– Reduction in cost due to economies of scale

• Some vendors already provide portal-like devices, but they are not standard and not interoperable.


What could a portal look like? Some Options:

`

ADSL

PLC

CableNetwork

SONET WAN

EMS

`

Portal in a meter

Portal in a local energy management systemPortal in a stand-alone device or PC

Portal in a set-top box



Possible User Interfaces

• A web page– Through Internet or directly

• A television interface– Similar to web interface

– Through a set-top box

• A simple control panel– Colors to indicate tariffs

– Buttons to control responses

• A single light – To indicate emergency curtailment

– To indicate level of rates applied

• ...or others



Characteristics

Every portal would have the SAME:

• Minimum data model

• Security scheme

• Upgrade mechanism– Tariffs

– Configuration

– Applications

The following things could be DIFFERENT:

• Innovative additions to the minimum data model

• In-building communications technology

• Wide-area network technology

• User Interface


What do YOU think?

• These have been some of the common ideas about portals

• Many people have different viewpoints

• Discussion: What do YOU think?

AMI / DR Reference Design CEC PIER Title 24 Reference

Design

Questions before proceeding

California Influence

CALIFORNIA ENERGY COMMISSION

Background The electricity crisis of 2000/2001 had many

contributing factors Market power (Enron, et al) Aging fossil fuel plants (pollution) Flaws in deregulation (AB 1890) Disconnect between wholesale and retail prices

However, most agree that one mitigating factor was missing

DEMAND RESPONSE


CEC Policy & Programs

Under the leadership of Commissioner Rosenfeld, the CEC along with the CPUC, CPA, and the State’s 3 major IOU’s embarked upon a path to encourage DR through “price-responsive” load

In support of this CEC policy and program, PIER initiated a DR Program to perform related R&D

Consultant Report: “A Strawman Reference Design for Demand Response Information Exchange” - http://ciee.ucop.edu/dretd/


Reference Design Project Genesis

Implementing DR policy requires implementing a demand responsive infrastructure

Stakeholders had widely varying views as to how such an infrastructure could be deployed

Most if not all of those views were incompatible with each other, were not based on standards, were not scaleable, and would have likely resulted in more stranded assets in the long run

The concept of a reference design as used in other industries came to mind as a way of mitigating this problem


LSE

ISO

UDC

Translation

Domain of “Open Systems”based information exchange

between “Applications”Open Systems Elements

Protocol (e.g. TCP/IP)Language (e.g. XML)Objects (e.g. independent of above)Security (e.g. HTTPS, SSL / TLS)

INT

ER

OP

ER

AB

ILIT

Y

ApplicationsMeteringDER/DA OperationsMaintenance

Information FlowReference Model

ApplicationsLoad aggregationBillingOn-line Services

ApplicationsGrid ManagementPrice CalculationDispatchMarket OperationsEmergency Control

Existing SystemsProprietary InterfacesSensor Networks-----------------------------Any protocolAny language

LegendISO – Independent System OperatorLSE – Load Serving EntityUDC – Utility Distribution Company

Back of the Napkin Concept


Characteristics of Infrastructure

Shareability - Common resources offer economies of scale, minimize duplicative efforts, and if appropriately organized encourage the introduction of competing innovative solutions.

Ubiquity - All potential users can readily take advantage of the infrastructure and what it provides.

Integrity - The infrastructure operates at such a high level of manageability and reliability that it is often noticeable only when it ceases to function effectively.

Ease of use - There are logical and consistent (preferably intuitive) rules and procedures for the infrastructure's use.


Characteristics of Infrastructure

Cost effectiveness - The value provided must be consistent with cost or the infrastructure simply will not be built or sustained.

Standards - The basic elements of the infrastructure and the ways in which they interrelate are clearly defined and stable over time.

Openness - The public infrastructure is available to all people on a nondiscriminatory basis.

Secure - The infrastructure must be protected against unauthorized access, interference from normal operation, and facilitate implementing information privacy policy


Demand Response Infrastructure: Principles and Goals

The DRI must provide a set of interfaces, transactions and services to support current and envisioned demand response functions.

The DRI must serve all constituents. The DRI must promote the principles of free

enterprise. The DRI must protect the rights of users and

stakeholders. The DRI must promote interoperability and open

standards.


Purpose of the DR Reference Design

To establish a common starting point for implementing open information exchange for a DR infrastructure whose characteristics include:

Scalability Interoperability Facilitating Innovation (cheaper, better, faster) Maintaining Compatibility (existing and proprietary systems)

Guarantees regulatory bodies the ability to develop tariffs, programs and other currently unknown initiatives

To protect the integrity of California’s power delivery system


Example:Emergency Load Curtailment

Present Day The ISO has no idea of how much ELC is available, how will or did the system

respond, nor is it enough to stabilize the system ISO issues command in different ways to different IOU’s Each IOU sends ELC signal to their subscribed loads using different methods

with varying latencies and feedback Future

Available ELC providers known to ISO through a common information system including stats on available ELC and expected response magnitude and delay

ISO broadcasts ELC signal using a single, standard method to all IOU’s, ESP’s, LSE’s, and other providers

Each provider relays ELC signal using standard interface to all subscribers Subscriber response is confirmed, logged, and reliability statistics are updated

and made available immediately to the ISO Regulators are able to audit program effectiveness, system capacity and actual

performance


Strawman Reference Design

Zones of information exchange Inside is a domain of open systems information

exchange Outside is a domain of existing and proprietary devices

and systems Between the two exists a defined set of

interfaces The reference design is the set of implementing

standards and technologies


Reference Design Components Actors - the entities that need to exchange information

(e.g., CAISO, LSE’s, and UDC’s) Applications - the functions that need to be performed by

the actors Protocol - the underlying communication methods used to

move bits and bytes Language - a common language to facilitate information

exchange Objects - high-level definitions of objects that are

independent of protocol and language Translation - services that provide a way to allow

information exchange with external systems Security - overarching methods to ensure confidentiality,

integrity, and availability


Domain of “Open Systems”based information exchange

between “Applications”

Open Systems ElementsProtocol (e.g. TCP/IP)Language (e.g. XML)Objects (e.g. CIM, ANSI, 61850)Transactions (e.g. GID, ebXML)Security (e.g. HTTPS, SSL / TLS)

INT

ER

OP

ER

AB

ILIT

Y

UDC ApplicationsMeteringDER/DA OperationsMaintenance

LSE ApplicationsLoad aggregationBillingOn-line Services

CAISO ApplicationsGrid ManagementPrice CalculationDispatchMarket OperationsEmergency Control

Customer ApplicationsBuilding ManagementAppliance OptimizationThermal ControlLoad Control

LegendISO – Independent System OperatorLSE – Load Serving EntityUDC – Utility Distribution Company

Translation ServicesExisting SystemsProprietary InterfacesSensor NetworksAny protocolAny language

Regulatory ApplicationsOversightRate validationCompliance

Demand Response Reference Design

Database ApplicationsData CollectionData StorageData ProcessingBilling FilesData PublishingData Archives


Interfaces and Transactions DR information exchange infrastructure is typically specified

in terms of interfaces and transactions. Interfaces constitute points of connection or interaction among system

components. They often refer to places where entities may offer services or link systems; they also may refer to the links at boundaries of layers of various functions.

Transactions specify sets of rules and formats that determine the communication behavior between entities

Any new system capability will have to connect via an existing or standard interface, even if some of the properties are tailored to the specific nature of the service.

It is essential that the system's key interfaces and transaction models be open to future evolution and development.

It is important to specify both the underlying services and the information objects exchanged across the infrastructure.


Review – The Premise

Demand Response (DR) will become a major resource to deal with California’s future electricity problems

An advanced metering infrastructure will be deployed on a large scale throughout the state

Price signals will be used to induce load response when contingencies and market imbalances exist

Technology will act as a proxy for end users (e.g. respond to signals and take action)


Implications

If the premise is true, then Information exchange will be required between

several organizations and systems Numerous applications that create and consume

information will exist


For there to be seamless exchange of information in ways that we can’t fully define today, there has to be a common reference design for California’s demand response infrastructure

Conclusion


Questions ???

California PCT CEC Title 24 Building Standards

Current code mandates PT’s 2008 revision mandates PCT’s

Specifies minimum requirements Points of Interoperability

Communications Interface HVAC Interface Human Interface Expansion Interface

California WAN -1 Way RDS Paging

Reasons for PCT Interface Specs One PCT for all of CA (US)

Retail purchased at Home Depot, etc.Consumer owned, installed, maintained

Common signaling throughout CA (US) Works with any minimum AMI system

Signals synched with AMI resolution Compatible with legacy technologies

Preserve richness of thermostat options

Title 24 Code Language (i) Thermostats – All heating and/or cooling systems shall

have a Programmable Communicating Thermostat (PCT) that meets the requirements of Subsections 150(i)(1) and 150(i)(2) below: (1) Setback Capabilities - All PCTs shall have a clock mechanism

that allows the building occupant to program the temperature set points for at least four periods within 24 hours. Setback thermostats for heat pumps shall meet the requirements of Section 112(b).

(2) Communicating Capabilities – All PCTs shall be distributed with a non-removable communications device that is compatible with the default statewide DR communications system (to be determined), which can be used by utilities to send price and emergency signals. PCTs shall be capable of receiving and responding to the signals indicating price and emergency events as follows.

Title 24 Code Language Price Events – The PCT shall be shipped with default price-

event offsets of +4°F for cooling and -4°F for heating; however, customers shall be able to change the offsets and thermostat settings at any time, except during emergency events. Upon receiving a price-event signal, the PCT shall adjust the thermostat setpoint by the number of degrees indicated in the offset for the duration specified in the signal of the price event.

Emergency Events – Upon receiving an emergency signal, the PCT shall respond to commands contained in the emergency signal, including changing the setpoint by any number of degrees or to a specific temperature setpoint. The PCT shall not allow customer changes to thermostat settings during emergency events.

And, the PCT Must: A. Include at least one industry standard

expansion/communication port. Insertion of a utility-specific communications module shall disable the default statewide communications hardware built in to the PCT unless the utility module is removed or is no longer receiving a signal.

B. Provide user information regarding communications system connection status, type of event (price or emergency), and other maintenance-related information. This information shall be on the standard PCT display, using a Liquid Crystal Display, standalone indicator using Light Emitting Diodes, or other means.

C. Be equipped with a standard connector on a wall plate capable of interfacing with the HVAC equipment. The connector shall have the capacity to support at least 6 analog thermostat wires, at least 3 digital communications wires, and 24 volt power supply.

PCT Architecturepower

memory

clock

CPU

other

volatilenon-volatile

communications

output

input

input

parallel

serial

output

input

internal

4-, 8-, 16-,32-bit μp{

{

output

I/O

analog

digital

expansionports

humaninterface

D/A

A/D

isolation

Basic (Mandatory) HVDC InterfaceTerm # Signal Name Normal

Color Notes

1 C: 24 Vac Common Black 24Vac transformer neutral 2 R: 24 Vac Power Red 24Vac transformer power. In a two source

transformer installation, this terminal becomes Rh.

(Conventional) Y: Cooling 3

(Heat Pump) Y: Compressor

Yellow Conventional - First stage cooling

Heat Pump - First stage compressor. Will heat and cool based on the output of terminal 5 - O/B

(Conventional) W: Heating 4

(Heat Pump) O/B: Compressor

White Conventional - First stage heating

Heat Pump – Configurable option to energize the terminal for cooling (O option) or heating (B option)

5 G: Fan Green Fan switch on thermostat or on a call for cooling or heat pump

6 (opt) Rc: 24 Vac Power Red OPTIONAL. Cooling transformer power for two source transformer installations. This terminal can be tied to terminal #2 in single transformer installations.

Advanced (Optional) InterfaceTerm # Signal Name Normal

Color Notes

(Conventional) W2: Second Stage Heating

7

(Heat Pump) Aux/E: Auxiliary Heating

Various Conventional - Second stage heating

Heat Pump – Auxiliary and emergency heating control relay.

8 Y2: Second Stage Cooling Blue or Orange

Second stage cooling for both Conventional and Heat Pump configurations

9 L: Equipment Fault Various Installed as an input based on equipment type. When configured as in input, activation of the external generated signal informs the user via icon or LED enunciation, that the heat pump system is not available.

Installed as an output based on equipment type. This output is used to “inform” zoning equipment that the system is in emergency heat mode. In this situation the secondary piece of equipment (zoning panel) will disable a call for heat pump.

(Conventional) W3: Third Stage Heating

10

(Heat Pump) Aux2: Second Stage Auxiliary Heating

Various Conventional - Third stage heating

Heat Pump – Second stage auxiliary heating

Communications Interface - WAN

Expansion Interface - MMC MMC System Specification Version 3.31 Serial Peripheral Interface (SPI) Optional: MMC version 4.1 or SDIO version 1.1

Communications: Messaging Model

Description of Messages & Data Payloads Required for the CEC Title 24 PCT Specification

Messages Recognize Two Basic System Event ModesPrice EventsEmergency Events

Messaging Model

Data Classes for Most MessagesAddressingEvent IdentificationTime StampingCrypto

Event ID ImportanceFacilitate cancellation of eventsPermit multiple event transmissions for

message transport reliability

Addressing Scheme Enables Regional or PCT Level FilteringPlace holder for value added information to

facilitate PCT side filtering Two Levels of PCT Operational Status

Visual Indication PossibleUnderlying Physical Communication Layer

e.g. – carrier heartbeatDerived from the last valid message received

Clock Sync Message PCT displays error message if a valid time sync

not received in 24 hr period

Price Events

Utility desire to communicate a “super peak rate” period is in effect either by:Simple message that price is in effectExplicit price

Price event message definitionStart and stop time & the price If the price field = zero then a generic super-

peak event with no specific price

Consumers PCT has default response to price event, but customer may override programming

PCT Vendors have design flexibility for owner response and / or event & price information

Reliability Events

Provides Utilities specific directives to PCT to address reliability Start and Stop TimeAdvance SchedulingReliability Selections

Change Temperature Set Temperature

Emergency Event – Special Reliability ClassCoded separately to facilitate expedited

handlingFor example

Normally, PCT events could be cached in area concentrator; then forward when network traffic permits

Area concentrator inspects message header and if emergency detected forwards message immediately with potential auto retransmissions

Messaging Specification – Data ClassesAddressing <ADDR> Common Addressing Information <ADDR>

Attribute Name Attr. Type Explanation M/ O

Data

Source Utility INT8U Utility / DisCo which controls the PCT (Ex: 5=SCE) M

DR Program INT8U Demand response program identifier (Ex: 3=CPP,1=non-curtailable) M

Area / Sub Ident INT16U Locates customer (Ex:0=ALL, 1..999 is area, 1000 up are substation idents M

Feeder Identifier INT8U Feeder number within a substation (0 = all feeders, 1..N = feeder) M

Billing Point Ident INT64U Identifies individual customer (ex: 5 = LADWP) O

Date/Time Stamp <DTIME> Common Date/ Time Information <DTIME>


Data

NTP_Seconds INT32U Seconds since 0h J anuary 1, 1900 UTC M

NTP_Fraction INT32U Fractional seconds M

Event Identification <EV_ID> Common Event Identifier <EV_ID>


Data

Event_ID INT16U Message serial number used for event identification, acknowledgement, and cancellation

M

Messaging Specification – Data Classes

Event Price <PRICE> Common Event Identifier <EV_ID>


Data

Event_Price INT16U $ / KWH * 0.0001 (Ex:2000 = $0.20 / KWH) M123

Event_Price_Ratio INT16U Event price is normal price x this_value / 100 (i.e. 200 means 2x price) M123

Event_Price_Tier INT8U Indicator of relative price (ex:1=normal, 2=high, 3=very high, >1000 is a Tier ID)

M123

Note: One of the three M123 elements is mandatory

Messaging SpecificationReliability Event – Change Temperature Reliability Event (change temperature) Command


Data

Command Code INT8U (ex: 3) M

Address <ADDR> Which PCTs should use this information (this may be ignored) M

Start_Time <DTIME> Event begin time M

Stop_Time <DTIME> Event end time M

Event_ID <EV_ID> Identifier of this price event (used for cancellation) M

Temp_Change INT8U Amount to change setpoint in 0.1 degree Celsius M

Crypto <CRYPTO> Message integrity value O

Note: Setpoint change sign is not specified – the thermostat knows which direction to change based on current mode for energy savings

Price Event Price Event Notification


Data

Command Code INT8U (ex: 2) M

Address <ADDR> Which PCTs should use this information (this may be ignored) M

Start_Time <DTIME> Event begin time M

Stop_Time <DTIME> Event end time M

Event_ID <EV_ID> Identifier of this price event (used for cancellation) M

Event_Price <PRICE> One of three possible price options – see <PRICE> M

Crypto <CRYPTO> Message integrity value O

Human Interface Requirements The PCT shall be shipped with default price-event offsets

of +4°F for cooling and -4°F for heating; however, customers shall be able to change the offsets and thermostat settings at any time, except during emergency events.

The PCT shall not allow customer changes to thermostat settings during emergency events.

Provide user information regarding communications system connection status, type of event (price or emergency), and other maintenance-related information. This information shall be on the standard PCT display, using a Liquid Crystal Display, standalone indicator using Light Emitting Diodes, or other means.

Through user input be capable of addressability at the substation level or finer including individual.

1. Introduction............................................................................................................................. 3 2. HVAC System Interface ......................................................................................................... 3

2.1 Minimal Direct Control Interface ........................................................................................ 3 2.2 Advanced Thermostat Direct Control Interface................................................................... 3 2.3 Digital Control Interface ...................................................................................................... 3

3. Expansion Interface ................................................................................................................ 3 4. Communications Interface ...................................................................................................... 3

4.1 Logical Information and Transaction Model .................................................................. 3 4.2 – PCT Functions ................................................................................................................... 3 4.3 – PCT Messages and Attributes ............................................................................................ 3

4.3.1 Event Modes .................................................................................................................. 3 4.3.2 Common Data Classes ................................................................................................... 3 4.3.3 Commands to PCT for minimum Title 24 Functionality............................................... 3 4.3.4 Additional Commands to PCT for Joint IOU Functionality .......................................... 3 4.3.5 Two-way functionality................................................................................................... 3

4.4 – PCT Transactions............................................................................................................... 3 4.4.1 – Sequence of events for one way communications enabled systems ........................... 3 4.4.2 – Sequence of events for two way communications enabled systems........................... 3

4.5 RBDS Implementation Profile ........................................................................................ 3 4.6 Two Way Pager Profile................................................................................................... 3

5. Human-Machine Interface ...................................................................................................... 3 5.1 PCT User Interface Requirements Summary........................................................................ 3

5.1.1 Title 24 PCT Code Language Rev 29b .......................................................................... 3 5.1.2 CEC Vision Document .................................................................................................. 3 5.1.3 IOU documents and presentations ................................................................................. 3

5.2 Standardized User Interface .................................................................................................. 3 6. Operational Issues and Expected Behaviors ........................................................................... 3

6.1 – Hold Button Behavior ........................................................................................................ 3 6.2 – Conflicting Message Behavior........................................................................................... 3 6.3 – Illogical Temperature Setpoint Behavior .......................................................................... 3

Annex A – Use Cases ..................................................................................................................... 3 A.1 – PCT Use Cases.................................................................................................................. 3 A.2 – CEC: A Vision of Demand Response 2015 ...................................................................... 3

Annex B – Glossary ........................................................................................................................ 3 Annex C – UC Berkeley PCT Research Report 3

PCT Reference Design TOC

Questions / Comments?

Formed in January 2005 in response to suggestion by the CEC PIER program as an outcome of publication of reference design report

Hosted as a child entity under the UCA International Users Group

OpenAMI accepted CEC reference design document as a starting point

OpenAMI Overview

2005 OpenAMI | www.OpenAMI.org Slide 75

UCAIug Sponsorship of OpenAMI — Justification

• Utility Communications Architecture International Users Group - UCAIug

• UCAIug Mission is to support Utility Communication in general

• Strong connection to IEC and IEEE – fast track to get to IEC international standard – but leave option open for other SDOs as well

• Large pre-existing utility and vendor participation

• Board members were willing to host this group


Mission StatementMission Statement

• Foster enhanced functionality, lower costs and rapid market

adoption

of Advanced Metering and Demand Response solutions through the

development of an open standards-based reference design & data

model

ObjectivesObjectives• Facilitate the broad adoption of advanced metering and demand response

• Define what ‘open standards’ means for advanced metering and demand response

• Diminish technical and functional risk concerns for utilities, regulators and rate-payers

• Empower consumers with tools to better understand and manage their energy use

• Foster industry innovation, efficiency and lower cost solutions

OpenAMI Task Force


OpenAMI Architecture

UDC AMI DomainAMI Network Domain

Wide Area Network(Private / Public)

AMI Network(Private / Public)

AMI Network Interfaces

Application Interfaces

Metering Systems

· Meter Reading

· Meter Lifecycle Management

· Meter Read Data Warehouse· Data Collection & Processing· Data Retrieval & Publishing· Data Storage & Archive

AMI System Domain

UDC Domain

· Billing

· CRM / CIS

· Distribution Operations

· Planning & Forecasting

· DER Operations

· Field Automation


LSE / ESP Domain

· Billing· On-Line Services· Load Aggregation· Planning & Forecasting


Regulators Domain

· Oversight· Compliance· Rate Validation· Security and System

Analysis & Audit


CAISO Domain

· Dispatch· Grid Management· Price Calculation· Market Operations· Emergency Control· Planning & Forecasting


· Billing· Planning & Forecasting


Market Bid Generation Provider Domain

Retail Energy Users or their Agents

Domain

· Meter Reading· Meter Lifecycle Management


· Building Energy Management· Appliance Control· Load Control (shed / generate)

Customer PremiseSystems & Equipment Domain

ApplicationInterfaces

Thermostat

FanPumpCompressor

GeneratorChiller

· Billing· DER Operations

Application InterfacesDistributed Energy

Resources Domain

PremiseInterfaces

Premise Interfaces

ApplicationInterfaces

AMI Meter Interfaces

AMI Network Interfaces

PremiseInterfaces

AMI Meter / Service Point Domain

AMI Meter Interfaces

Premise Interfaces

AMI Comm Interface

Meter Interface

SRDDisconnectInterface

Meter Service Companies Domain

Well defined points of interoperability,

interfaces, transactions, and

information models

http://www.openami.org/


UtilityAMI Overview

UtilityAMI Overview

Formed in November 2005 to address lack of utility guidance

Need for requirements to be driven by entities who will buy AMI systems and their components - utilities

UCA International Users Group

UCAIUG Technical Committee

Intelligent Grid Working Group

UtlityAMI Advisory Group

Requirements Task Group

EnterpriseArchitecture Task Group

OpenAMI Task Force

Data Model Task Group

Reference Design Task

Group

Interoper-ability Task

Group

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.

Glossary: Definition of AMI

An advanced metering infrastructure is a comprehensive, integrated collection of devices, networks, computer systems, protocols and organizational processes dedicated to distributing highly accurate information about customer electricity and / or gas usage throughout the utility and back to the customers themselves.


Such an infrastructure is considered “advanced” because it not only gathers customer data automatically but does so securely, reliably, and in a timely fashion while adhering to published, open standards and permitting simple, automated upgrading and expansion.


A well-deployed advanced metering infrastructure enables a variety of utility applications to be performed more accurately and efficiently including time-differentiated tariffs, demand response, outage detection, theft detection, network optimization, and market operations.

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 ForceSecurity issues and their relationship to business needs

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

5. AMI Network InterfacePolicy for AMI network to MDMS interfacing

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

7. General Issues Forum

Common Requirements Document

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.

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

Requirements Voting Results

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)

Status and Next Steps

Task 1 complete Glossary published on collaboration site Web version of glossary accessible to members Technology capability evaluation method published by

SCE (http://www.sce.com/ami/ ) – no longer a UtilityAMI subtask

Common requirements approved August 4, 2006 Task 2 (modular interface) – transferred to

OpenAMI Task 3 (Security) draft scoping document prepared

First meeting this Thursday Task 4 (Consumer Interface) – this workshop! Task 5 (Meter to MDM Interface) – not started Task 6 (MDM to Enterprise Interface) – Coming

soon Other – AMI Vendor Database – online now

http://www.sce.com/ami/

HAN Task Force Scope

High level reference design/architecture

Utility Requirements Information Models Security

Stakeholders and Collaborators

Utility driven Vendor input required

Hardware – network, devices Associations – e.g. ZigBee, ZWave,

Etc. Standards Groups

Envisioned Deliverables

HAN Principles and Framework HAN Use Cases HAN Requirements Device Models (or another TF) Security Model (of another TF)

Questions

After the break, we will see what OpenHAN has done to address these objectives

Open Discussion

UtilityAMI OpenHAN TFActivity Summary

HAN Guiding Principles, Use Cases, System Criteria

TF Operating Rules

OpenHAN is a TF of the UtilityAMI WG and operates under the same governing rules

This is a utility driven activity Members in good standing of the UCA

International Users Group which represent a utility are eligible to vote

Utility members are permitted to put any issue on the table for discussion or vote

Any member may contribute / comment A majority of utility members may vote to table

any issue

OpenHAN Overview

Outline:Framework introductionDocumentation PurposeDocumentation ProcessGuiding Principles Functional Characteristics Use Cases System CriteriaNext Steps - Requirements Process

AMI Opportunity for HAN

1000 MW of Peak Demand Response by 20151

0.5% Annual energy conservation effect across all customers1

Enables energy information for customers without internet access Satisfy higher customer experience expectations Ubiquitous deployment provides market catalyst for enabling

energy innovation for customers

Now is the right time• Viable open standards based protocols exist• Incremental HAN in meter cost is <2% of program capital costs • Cost effective based on initial limited use – low financial impact from

risk of stranded technology• If not now – next opportunity for ubiquitous deployment is 15 – 20

years

1. Based on SCE Dec. 2006 preliminary business case analysis, subject to revision

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

Communication Specification Example

ValueProposition

Vision &Guiding Principles

Functional Characteristics &

Criteria

Platform Independent Requirements

Platform Requirements (Technology Specific)

openHA

N C

ompliant

- Enable Demand Response- Enable energy information for customers without internet access- Satisfy higher customer experience expectations - Enable energy innovation for customers

- Provide secure two-way communications- Support command and control signaling- Support consumer specific signaling - Support ownership model

- Provide an agile communication capability - Provide adequate capacity - Provide communication reliability - Provide adequate communication control

- Requirements: Shall not interfere with other networks- Requirements: Shall allow coordination/control transfer - Requirements: Shall provide product interoperability - Architecture: Define communication control

- Shall be 802.15.4 (Low Rate WPAN) compliant - Shall be IEEE P1901 compliant- Shall use direct-sequence spread spectrum coding- Shall use deficit weighted round robin (DWRR) for scheduling

Utility Specific

Example Needs and Requirements

Security Specification Example

ValueProposition

Vision &Guiding Principles

Functional Characteristics &

Criteria


Platform Requirements (Technology Specific)

openHA

N C

ompliant

- Enable Demand Response- Enable energy information for customers without internet access- Satisfy higher customer experience expectations - Enable energy innovation for customers

- Provide secure two-way communications- Support command and control signaling- Support consumer specific signaling - Support customer ownership model

- Provide a robust cryptographic capability for load control signaling - Provide a cryptographic capability for energy information sharing - Provide a secure device registration and authentication capability- Provide a robust audit capability

- Requirements: Shall use FIPS 197 (AES) for symmetric cryptography- Requirements: Shall use third party materials for authentication - Architecture: Define Commissioning and registration process- Architecture: Define Command and Control Signaling

- Shall use MAC layer security as specified in 802.15.4 - Shall use CCM mode (Counter with CBC-MAC) for block ciphers- Shall fully support EAP-PSK (RFC 4764)- Shall use EAP-TLS, defined (RFC 2716)

Utility Specific

Example Needs and Requirements

OpenHAN Documentation Purpose

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 Information sharing with other stakeholders

Documentation Process (Ratified)

Utility Specific Value Proposition

Bus

ines

s N

eeds

Business Continuity Needs

Assessment

RegulatoryCompliance

Analysis

Prog

ram

Nee

ds

Common Purpose Common Vision

Indu

stry

Ena

bler

s

Common Principles

CA IOUValidation

Compliance Validation

Use Cases

OpenHAN Vetting and Refinement

System Criteria

OpenHAN Assessment

Platform Independent Requirements and Architecture

Ope

nHA

N D

ocum

enta

tion

Proc

ess

Technology Platforms and Alliances

Aug 15 Ratification Date

Examples: PUC, SOX, NERC, etc.

Ratified

Ratified

HAN Guiding Principles

Value Proposition

Guiding Principles

Use Cases


Platform Requirements


System Criteria

HAN Guiding Principles (Ratified 7/11/2007)

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

HAN Use Cases

Value Proposition

Guiding Principles

Use Cases




System Criteria

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)

Utility/Consumer Interface Architectures Considered

Meter as sole gateway to HAN Support use cases Lowest cost, meets business case Can be implemented over 4 years ubiquitously to all 5 million customers Seen as starting point for eventual shift to customer gateway controlled HAN

Meter as interface to in-home gateway (with protocol converter as needed) Supports use case Higher cost, may require customer knowledge / configuration Seen as eventual end state over life of system

Third party gateway(s) only to load control devices Slow market adoption – could take 10 years to reach 70% market penetration like

internet Does not support near-real time access to energy data from meter at no incremental

cost to customer Security, network management, QOS more challenging If challenges met, compatible with overall architecture Avoids meter interface technology obsolescence

Scenario A: Meter as Gateway

Utility Owned

Consumer Owned

Private Fixed NetworksWAN/LAN

Meter

2-way

T24 PCT

RDS/FM or pager broadcast(disabled when utility network

operational)

1-way

Appliance

Sub-meter

Display Devices

1.e.g., 802.11b, proven mesh LAN protocol, etc.

2-way

• interval energy• time• billing start time• peak power• messages• acknowledgements• price signals• reliability signals

RF-TX1

Third-Party Provider

Scenario B: Evolution to Multiple Gateway Model

Utility Owned

Consumer Owned

Private Fixed NetworksWAN/LAN

Anyintervalmeter

or pole-topcollector

PSTN/DSL/Cable/SatelliteWAN/LAN

2-way 2-way

Any gateway (protocol xfr)

•Special box•Internet modem•Router•Media PC•Security panel• ……..

HAN Protocols³ZigbeeZ-waveInsteon

Wi-FiEIA709

HomePlugBluetooth

2-wayT24 PCT

RDS/FM or pager broadcast

1-way

2-way

HAN access using expansion port

Sub-meter

Appliances

Display Devices

1.e.g., 802.11b, proven mesh LAN protocol, etc.2.To be determined3.Up to 45 active protocols worldwide

Broadband TV, music

2-way

2-way

2-way


RF-TX1

PLC-TX²and/or





2-way

Ron Hofmann

2-way

Scenario C: 3rd Party Communication Channel/Gateways Only(Out of Scope for OpenHAN)

Utility Owned

Consumer Owned

Private Fixed Networks2

WAN/LAN

Anyintervalmeter

PSTN/DSL/Cable/SatelliteWAN/LAN

2-way

2-way

Any gateway (protocol xfr)

•Special box•Internet modem•Router•Media PC•Security panel• ……..

HAN Protocols³ZigbeeZ-waveInsteon

Wi-FiEIA709

HomePlugBluetooth

2-wayT24 PCT

RDS/FM or pager broadcast

1-way

2-way

HAN access using expansion port

Other

Appliances

Display Devices

1.Utility information to/from utility network2.Up to 45 active protocols worldwide

Broadband TV, music

2-way

2-way

2-way






Ron Hofmann

utility.com

Use Case Organization

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

Load Control and Energy Management Voluntary Mandatory Opt-out

Energy Management System Energy Storage and Distribution User Information Submetering

System Management and Configuration

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

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

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

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

diagnostics HAN Device Diagnostics – covers on-site troubleshooting steps

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

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

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

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

EV/PHEV premise/account/device bindings)

Load and Energy Management

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

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

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

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

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

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

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

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

HAN Devices receive optional warning messages Mandatory events require gateway acknowledgement

Energy Management System

Covers the utility to EMS interactions Assumptions and Notes

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

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

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

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

Energy Storage and Distribution

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

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

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

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

User Information

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

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

other utility functionalitiesThe IHD is either pre-programmed to respond

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

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

Submetering

Covers the measurement of other metering devices within the HAN

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

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

AMI system provides pricing information to the sub metering devices.

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

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

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

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

Motion for Voting

Move to accept the Load and Energy Mangement,Energy Storage and Generation,System Configuration and Management,User Information,and Energy Management System

HAN use cases as well as the Introduction and Definitions supporting documents submitted by the Use Case Work Team and (as will be amended according to the agreements reached during discussion) as a base set for the purpose of starting the platform/technology independent requirements development process.

OpenHAN Use Cases

Ratified unanimously by the six utilities in attendance 8/15/2007AEPConsumers EnergyEDFPG&ESCESDG&E

Other utilities may ratify after review

HAN System Criteria and Functional Characteristics

Value Proposition

Guiding Principles

Use Cases




System Criteria

HAN Functional Characteristics and System Criteria

Applications

DirectControl

Cycling Control

Limiting Control

Distributed Generation

Submetering

EnvironmentState

Device State

EnergyCost

Energy Production

Energy Optimization

Energy Demand

Reduction

EnvironmentImpact

UserInput

UserOutput

ControlHuman

MachineInterface

MeasureMonitor

System*

Communications

Discovery Control

Announce

Respond

InitialIdentify

Identify

Authenticate

Configure

Organize

Optimize

Prioritize

Mitigation

Security PerformanceOperations

MaintenanceLogistics

Availability Reliability Maintain-

ability

Scalability Upgrade-

ability Quality

Lev

el 4

Lev

el 2

Lev

el 3

Lev

el 1

Integrity Account-

abilityRegistration

Authentication

AccessControl

Confidenti-ality

Public

Private

Utility

Initialization

Validation

Correlation

Resistance

Recovery

Audit

Non-Repudaition

Revocation

Pre-commision

Registrationconfig

Labeling

Document

Support

AlarmLogging

Testing

Reset

Installation ManufactureDistribute

Manage Maintain

Purchasing


CommisionProcessing

Energy Consumption

Authorization

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

Functional Characteristics and System Criteria

Criteria and characteristics provides non authoritative context and clarification Viewed as technology enablers Driven by Guiding principles and use cases Establishes high level technical expectations Organized by behavior and function Includes Application, Communications, Security and Privacy and Performance

Application Criteria Utility functionality Know consumer functionality Application evolution and migration

Communication Criteria Logical and physical communication decoupling (AMI Backhaul and HAN) Interoperability and interference (e.g., customer gateways, networks) Communication evolution

Security and Privacy Graduated model (low, medium, high robustness) based on signal type Authentication, Authorization and Accountability

Authentication material: source, distribution flows Authorization (rights): device registration, participation and revocation Accountability: audit, alerts and non-repudiation

Performance (Adaptability, Flexibility, Scalability, Reliability, etc.) Operations, Maintenance, Logistics

HAN Application Characteristics

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

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

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

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

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

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

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

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

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

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

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

Display, text message)

HAN Communications

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

entity) Initial Identification - Device-type and address identification

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

bindings) Control Autonomous functions enabled by the platform specific

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

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

through detection and analysis of environmental conditions

HAN Security

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

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

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

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

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

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

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

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

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

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

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

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

HAN Performance

Availability - The applications are consistently reachable

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

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

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

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

Quality - The applications will perform as advertised

HAN Operations, Maintenance and Logistics

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

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

wholesale, utility) Installation - physical placement of the device

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

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

Alarming and logging - Event driven consumer and utility notifications

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

HAN Platform Independent Requirements

Value Proposition

Guiding Principles

Use Cases

Platform Independent

Requirements



System Criteria

Requirements Process Proposal

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

requirements For each level four category generate advanced (optional)

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

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

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

Basic Requirements Advance Requirements

Use OpenHAN TF Vetting Process

Requirements Process Proposal (continued)

Applications

ControlHuman

MachineInterface

MeasureMonitor

Registration

Communications

Discovery Control

Security PerformanceOperations

MaintenanceLogistics

Availability Reliability Maintain-

ability

Le

vel 2

Le

vel 3

Use

Ca

se

Integrity Account-

abilityRegistration

Authentication

AccessControl

Confidenti-ality

Installation ManufactureDistribute

Manage Maintain

CommisionProcessing

Installation and Provisioning

Depot Configuraiton

Maintenance and Troubleshooting

Remote Diagnostics

Le

vel 4

See System Criteria for Level 4 Details

Bas

icA

dv

anc

ed

Req

uir

emen

ts

Requirements Analysis

Submetering

User Information

Load and Energy Management

EMS

Energy Storage and Distribution

Next Steps

Develop OpenHAN platform independent requirements Ratify Requirements Continue to share information with technology

communities (i.e., vendors, alliances) Provide advice and guidance to working groups and

task forces of OpenAMI and UtilityAMI working on specific technology mappings and applications guidelines (e.g. information models, security profiles, communication profile mappings)

General Discussion

We need feedback Does the process make sense? How do you see the HAN evolving? What industry do you see driving the

HAN? How do multiple HAN’s co-exist and

cooperate – or stay out of each others way?

Is what we have done so far useful? What use cases (scenarios) are

missing?


AMI / DRI Security

AMI Security – Statement of Objectives

“AMI Security must facilitate the easy exchange of high resolution electric load and usage data between the customer and the utility while maintaining customer privacy and protecting critical infrastructure”

Do the NERC CIP Standards Apply to AMI?

The answer to this revolves around two key issues: Definition of Critical

Infrastructure Placement of Electronic

Security Perimeter

Do the NERC CIP Standards Apply to AMI?

CIP-002-1 Critical Cyber Asset Identification dictates that the utility will use a risk-based assessment to identify Critical Assets.

The requirement relevant to AMI is the following item: R1.2.5. Systems and facilities critical to

automatic load shedding under a common control system capable of shedding 300 MW or more.


Title 24 PCT Security

California Title 24California Title 24

Building Code Update for 2008Building Code Update for 2008 Requires installation of PCTs for new Requires installation of PCTs for new

constructionconstruction Purpose is to ensure a baseline resource for Purpose is to ensure a baseline resource for

demand responsedemand response Utilizes a California wide communications Utilizes a California wide communications

infrastructureinfrastructure IOUs can utilize their own AMI network IOUs can utilize their own AMI network

insteadinstead

PCT SecurityPCT Security

Programmable Communicating ThermostatProgrammable Communicating Thermostat Dovetails into AMIDovetails into AMI Designed to work “stand-alone” (one-way Designed to work “stand-alone” (one-way

communications)communications) Mandated by law in CaliforniaMandated by law in California

IssuesIssues Needs to work to enable Demand-ResponseNeeds to work to enable Demand-Response Must authenticate broadcast signalsMust authenticate broadcast signals Distributed through variety of channelsDistributed through variety of channels Resource-constrained platformResource-constrained platform

Fundamental Strategic ObjectivesFundamental Strategic Objectives

ResistanceResistance Protect Access and ControlProtect Access and Control

ResilienceResilience Limit Damage and LossLimit Damage and Loss

RecoveryRecovery Regain Confidence in Safe, Regain Confidence in Safe,

Reliable OperationReliable Operation

AssumptionsAssumptions

Human FactorsHuman Factors Organizational Lapses, Honest Error, MaliceOrganizational Lapses, Honest Error, Malice

Practical RecoveryPractical Recovery Replacement / Repair Costs, Negative PublicityReplacement / Repair Costs, Negative Publicity

Security PrioritiesSecurity Priorities 1) Authentication, 2) Message Integrity1) Authentication, 2) Message Integrity

Distribution ChannelsDistribution Channels Manufacturers, Utilities, Retail ChannelsManufacturers, Utilities, Retail Channels

FeedbackFeedback Error Codes, Serial/Model #, Customer Info, Date/Time/LocError Codes, Serial/Model #, Customer Info, Date/Time/Loc

Risk Management ApproachRisk Management Approach

VulnerabilitiesVulnerabilities Frequency x SeverityFrequency x Severity

MappingMapping Threats through Threats through

Vulnerabilities to AssetsVulnerabilities to Assets MitigationMitigation

Reduce, Transfer, AcceptReduce, Transfer, Accept

AssetsAssets Value, Sensitivity Aspect (C-I-A)Value, Sensitivity Aspect (C-I-A)

ThreatsThreats Possible Source, Intent, StrengthPossible Source, Intent, Strength

Possible AttacksPossible AttacksApplication LayerApplication Layer Sudden LoadSudden Load Recall Authentic SignalRecall Authentic Signal Load ShedLoad Shed Software DownloadSoftware Download False AcknowledgementFalse Acknowledgement False Time SynchFalse Time Synch False Display MessagesFalse Display Messages Gaming the SystemGaming the System

Transport LayerTransport Layer Control of Head-End Radio Control of Head-End Radio

SystemSystem DoS Head-EndDoS Head-End Interception of Wireless Interception of Wireless

MessageMessage

Physical LayerPhysical Layer Signal Jamming / False Signal Jamming / False

MessagesMessages Ground Station or VehicleGround Station or Vehicle Balloon / AircraftBalloon / Aircraft

Customer Disables Customer Disables Thermostat AntennaThermostat Antenna

Possible AttacksPossible Attacks

Non-Cryptographic Mitigation MethodsNon-Cryptographic Mitigation Methods

PrinciplesPrinciples Time As Ally – Slow the AttackTime As Ally – Slow the Attack Limit Allowable BehaviorLimit Allowable Behavior Detection As Well As PreventionDetection As Well As Prevention

Business LogicBusiness Logic Acceptable Commands, Random Delay On Acceptable Commands, Random Delay On

Cancel, Hard Limits, Time SynchCancel, Hard Limits, Time Synch Detection and EnvironmentDetection and Environment

IDS, Heartbeat, Historical Data, Tamper DetectionIDS, Heartbeat, Historical Data, Tamper Detection

Non-Cryptographic Mitigation MethodsNon-Cryptographic Mitigation Methods

System Recommendations

IDS

Frequent Time Update

Logical Gaming Detection

Tamper Detection

External Factors / Influence

Incentives

Legislation

Crypto Algorithm

Key Administration

Asymmetric Keys

Key Splitting

Key Distribution

Key Management

KEYS & CRYPTO

Compromise Head-End

Jam Broadcast Signal

Falsify / Forge Data

Disable Antenna

Locally Change PCT Time

ATTACK MECHANISM DETECTION

Radio Stations

FCC

ENVIRONMENT

Layers of Defense

No Remote Load Increase

Safety Limits

Random Recovery Delays

Initial Setback Recovery Limit

Override Local Time Set

Simultaneous Addressing Limits

BUSINESS LOGIC

Audit Logs

Message ContentMessage Content

TimestampTimestamp Message IdentifierMessage Identifier

Use cryptographic nonce principlesUse cryptographic nonce principles PCT remembers most IDs usedPCT remembers most IDs used

Valid range only slightly larger than PCT memoryValid range only slightly larger than PCT memory Difficult to guess unused IDDifficult to guess unused ID

Timestamp + ID Timestamp + ID Unique Content Unique Content Regardless of instructionRegardless of instruction Complimented by use of an HMACComplimented by use of an HMAC

Cryptographic Mitigation ApproachesCryptographic Mitigation Approaches

Secret Sharing (a.k.a. “Key Splitting”)Secret Sharing (a.k.a. “Key Splitting”)Asymmetric CryptographyAsymmetric Cryptography

Registration Registration Use CaseUse Case

1.1. InstallerInstaller retrieves random number from retrieves random number from PCTPCT..2.2. InstallerInstaller contacts contacts System OperatorSystem Operator via out-of-band channel. via out-of-band channel.3.3. InstallerInstaller relays relays PCTPCT random number to random number to System OperatorSystem Operator..4.4. System OperatorSystem Operator relays relays PCTPCT random number to random number to System System

OwnerOwner..5.5. System OwnerSystem Owner performs two XOR operations: performs two XOR operations:

With With PCTPCT random number and random number and System Owner’sSystem Owner’s primary primary public keypublic key

With With PCTPCT random number and random number and System Owner’sSystem Owner’s backup backup public key.public key.

6.6. System OwnerSystem Owner sends results of XOR operations to sends results of XOR operations to System System OperatorOperator..

7.7. System OperatorSystem Operator performs XOR operation with performs XOR operation with PCTPCT random random number and number and System Operator’sSystem Operator’s public key. public key.

8.8. System OperatorSystem Operator transmits registration signal including the transmits registration signal including the labeled results of all three XOR operations to labeled results of all three XOR operations to PCTPCT..

9.9. PCTPCT performs XOR operation with its random number and performs XOR operation with its random number and each of the three result numbers received via registration each of the three result numbers received via registration signal, recovering three labeled public keys.signal, recovering three labeled public keys.

10.10. System OwnerSystem Owner encrypts activation message with encrypts activation message with System System Owner’sOwner’s primary public key. primary public key.

11.11. System OwnerSystem Owner sends (encrypted) activation message to sends (encrypted) activation message to System OperatorSystem Operator..

12.12. System OperatorSystem Operator encrypts activation message with encrypts activation message with System System Operator’sOperator’s private key. private key.

13.13. System OperatorSystem Operator transmits (double encrypted) activation transmits (double encrypted) activation message to message to PCTPCT..

14.14. PCTPCT decrypts activation message: first with decrypts activation message: first with System System Operator’sOperator’s public key; second with public key; second with System Owner’sSystem Owner’s primary primary public key.public key.

15.15. PCTPCT activates. activates.

Key ManagementKey Management

Sole purpose of Sole purpose of Backup key would Backup key would be to distribute be to distribute new Primary key.new Primary key.

Operator keys Operator keys may represent may represent regions, regions, substations, substations, territories, etc…territories, etc…

Remaining IssuesRemaining Issues

Finalize AlgorithmsFinalize Algorithms ECC RecommendedECC Recommended Hashing, Key Wrapping Still To Be Hashing, Key Wrapping Still To Be

DeterminedDeterminedFinalize Number of Levels, Groups of Finalize Number of Levels, Groups of

KeysKeysDetermine Frequency of Time Signal / Determine Frequency of Time Signal /

Heartbeat MessageHeartbeat Message

Final DiscussionFinal Discussion

What have we missed?What have we missed?You can contributeYou can contribute

UtilityAMI – General RequirementsUtilityAMI – General Requirements OpenHAN – HAN RequirementsOpenHAN – HAN Requirements AMI-SEC – Security Geeks OnlyAMI-SEC – Security Geeks Only AMI-Enterprise – SOA for MDMS / CISAMI-Enterprise – SOA for MDMS / CIS OpenAMI – Vendors building stuffOpenAMI – Vendors building stuff OpenPCT – Title 24 implementationOpenPCT – Title 24 implementation

For any additional information, please do not hesitate to contact us Erich W. Gunther

EnerNex Corporation Phone: 865-691-5540 ext. 114

[email protected]

http://www.utilityami.org/http://sharepoint.ucausersgroup.org/http://sharepoint.ucausersgroup.org/openami/http://sharepoint.ucausersgroup.org/openhan/http://sharepoint.ucausersgroup.org/utilityami/amisec/

Contact Us

Erich W. Gunther, P.E. Chairman and CTO EnerNex Corporation [email protected] Chairman UtilityAMI,...

Documents

Transcript of Erich W. Gunther, P.E. Chairman and CTO EnerNex Corporation [email protected] Chairman UtilityAMI,...