Home Area Network Workshop Erich W Gunther P

Home Area Network Workshop Erich W. Gunther, P. E. Chairman and CTO Ener. Nex Corporation [email protected] com Chairman Utility. AMI, Open. HAN, CA Title 24 PCT Reference Design Task Force

Agenda • Introductions • Context Setting • EPRI Consumer Portal Project Overview • California Influence • Reference Design for AMI and DRI • Demand Response –Title 24 PCT • Industry Response • • Open. AMI Overview • Utility. AMI Overview Questions and Discussion Break Open. HAN – What have we been up to? Security – Examples, Issues, Opportunities Questions and Discussion Adjourn - Lunch

EPRI Consumer Portal Overview q Questions before proceeding?

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? Consumer Portal FAQ Copyright © EPRI 2005 – 4

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. ” Consumer Portal FAQ Copyright © EPRI 2005 – 5

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 Consumer Portal FAQ Copyright © EPRI 2005 – 6

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 Consumer Portal FAQ Copyright © EPRI 2005 – 7

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 Consumer Portal FAQ Copyright © EPRI 2005 – 8

Why are we talking about portals? Portals Lead to an Intelligent Power Grid • The Intelli. Grid 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 Consumer Portal FAQ Copyright © EPRI 2005 – 9

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 Consumer Portal FAQ Copyright © EPRI 2005 – 10

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. Consumer Portal FAQ Copyright © EPRI 2005 – 11

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 Consumer Portal FAQ Copyright © EPRI 2005 – 12

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. Consumer Portal FAQ Copyright © EPRI 2005 – 13

What could portals do? Advanced Metering and Demand Response Consumer Portal FAQ Copyright © EPRI 2005 – 14

What could portals do? Residential Customer Services Consumer Portal FAQ Copyright © EPRI 2005 – 15

What could portals do? Advanced Customer Services • Integrate with local Energy Management System • Optimize energy use • Compute energy efficiency Consumer Portal FAQ • • • Control distributed generation Coordinate load profiles between buildings Submit bids to energy markets Copyright © EPRI 2005 – 16

What could portals do? Customer Management • Remotely connect or disconnect customers • Detect tampering • Detect theft of energy • Limit maximum load in response to billing irregularity Consumer Portal FAQ Copyright © EPRI 2005 – 17

What could portals do? Widespread Distribution of Data • Provide large volumes of accurate data • for marketing, simulation, modeling, and predictive maintenance • Consumer Portal FAQ Aggregate data from multiple types of utilities Stagger load pickup in “black start” emergencies Copyright © EPRI 2005 – 18

What could portals do? Advanced Distribution Operations • • • Detect and isolate outages more quickly Shed load with finer control Use demand response customers as a “fast reserve” Consumer Portal FAQ • • • Monitor and optimize power quality more accurately Monitor and control distributed generation Minimize system losses Copyright © EPRI 2005 – 19

What could portals do? Non-Energy Applications Also: • • Weather forecasting Flooding and freezing alerts Air quality Optimize building heating and lighting Consumer Portal FAQ Copyright © EPRI 2005 – 20

Which portal functions are most important? • Feedback from Intelli. Grid Consortium members Consumer Portal FAQ Copyright © EPRI 2005 – 21

How Could Portals Make Money? Benefits: Barriers: • Increased system efficiency, stability, and power quality • Cost of equipment • Cumulative savings from demand response • Avoided costs of incremental capital investment • Recovered costs: – 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 – Theft detection – Fewer outages • New income: – New value-added services – Participation in markets with better data Consumer Portal FAQ – Signing up customers – Technical support – Billing infrastructure Copyright © EPRI 2005 – 22

How could portals make money? EPRI Study - 2004 • • • 5 -20 year assessment of California market 15% discount rate assumed $15 B benefit to society AFTER investors have earned 15%! Consumer Portal FAQ Copyright © EPRI 2005 – 23

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 Consumer Portal FAQ Copyright © EPRI 2005 – 24

What could a portal look like? • A consumer portal is an idea, not a particular device! • Intelli. Grid 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. Consumer Portal FAQ Copyright © EPRI 2005 – 25

What could a portal look like? Some Options: Portal in a meter Portal in a set-top box Portal in a stand-alone device or PC Portal in a local energy management system Consumer Portal FAQ Copyright © EPRI 2005 – 26

What could a portal look like? 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 Consumer Portal FAQ Copyright © EPRI 2005 – 27

What could a portal look like? Characteristics Every portal would have the SAME: The following things could be DIFFERENT: • Minimum data model • Innovative additions to the minimum data model • Security scheme • Upgrade mechanism – Tariffs – Configuration – Applications • In-building communications technology • Wide-area network technology Consumer Portal FAQ • User Interface Copyright © EPRI 2005 – 28

What do YOU think? • These have been some of the common ideas about portals • Many people have different viewpoints • Discussion: What do YOU think? Consumer Portal FAQ Copyright © EPRI 2005 – 29

California Influence AMI / DR Reference Design q CEC PIER Title 24 Reference Design q q Questions before proceeding

Background The electricity crisis of 2000/2001 had many contributing factors w w 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 CALIFORNIA ENERGY COMMISSION

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 “priceresponsive” 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/ CALIFORNIA ENERGY COMMISSION

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 CALIFORNIA ENERGY COMMISSION

Back of the Napkin Concept CALIFORNIA ENERGY COMMISSION

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. CALIFORNIA ENERGY COMMISSION

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 CALIFORNIA ENERGY COMMISSION

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. CALIFORNIA ENERGY COMMISSION

Purpose of the DR Reference Design To establish a common starting point for implementing open information exchange for a DR infrastructure whose characteristics include: w w 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 CALIFORNIA ENERGY COMMISSION

Example: Emergency Load Curtailment Present Day w w w 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 w w w 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 CALIFORNIA ENERGY COMMISSION

Strawman Reference Design Zones of information exchange w w 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 CALIFORNIA ENERGY COMMISSION

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 CALIFORNIA ENERGY COMMISSION

CALIFORNIA ENERGY COMMISSION

Interfaces and Transactions DR information exchange infrastructure is typically specified in terms of interfaces and transactions. w w 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. CALIFORNIA ENERGY COMMISSION

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) CALIFORNIA ENERGY COMMISSION

Implications If the premise is true, then w w Information exchange will be required between several organizations and systems Numerous applications that create and consume information will exist CALIFORNIA ENERGY COMMISSION

Conclusion 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 CALIFORNIA ENERGY COMMISSION

Questions ? ? ? CALIFORNIA ENERGY COMMISSION

California PCT n CEC Title 24 Building Standards ¨ ¨ Current code mandates PT’s 2008 revision mandates PCT’s n n Specifies minimum requirements Points of Interoperability ¨ Communications Interface ¨ HVAC Interface ¨ Human Interface ¨ Expansion Interface n California WAN -1 Way ¨ RDS ¨ Paging

Reasons for PCT Interface Specs n One PCT for all of CA (US) ¨ Retail purchased at Home Depot, etc. ¨ Consumer owned, installed, maintained Common signaling throughout CA (US) n Works with any minimum AMI system n ¨ Signals n synched with AMI resolution Compatible with legacy technologies ¨ Preserve richness of thermostat options

Title 24 Code Language n (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 n Price Events – The PCT shall be shipped with default priceevent 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 thermostat setpoint by the number of degrees indicated in the offset for the duration specified in the signal of the price event. n 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: n 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. n 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. n 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 Architecture

Basic (Mandatory) HVDC Interface

Advanced (Optional) Interface

Communications Interface - WAN

Expansion Interface - MMC n n n 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 n Messages Recognize Two Basic System Event Modes n ¨ Price Events ¨ Emergency Events

Messaging Model n Data Classes for Most Messages ¨ Addressing ¨ Event Identification ¨ Time Stamping ¨ Crypto n Event ID Importance ¨ Facilitate cancellation of events ¨ Permit multiple event transmissions for message transport reliability

n Addressing Scheme Enables Regional or PCT Level Filtering ¨ Place holder for value added information to facilitate PCT side filtering n Two Levels of PCT Operational Status Visual Indication Possible ¨ Underlying Physical Communication n e. g. – carrier heartbeat Layer ¨ Derived from the last valid message received n Clock Sync Message n PCT displays error message if a valid time sync not received in 24 hr period

Price Events n Utility desire to communicate a “super peak rate” period is in effect either by: ¨ Simple message that price is in effect ¨ Explicit price n Price event message definition ¨ Start and stop time & the price ¨ If the price field = zero then a generic superpeak event with no specific price

Consumers PCT has default response to price event, but customer may override programming n PCT Vendors have design flexibility for owner response and / or event & price information n

Reliability Events n Provides Utilities specific directives to PCT to address reliability ¨ Start and Stop Time ¨ Advance Scheduling ¨ Reliability Selections Change Temperature n Set Temperature n

n Emergency Event – Special Reliability Class ¨ Coded separately to facilitate expedited handling ¨ For example Normally, PCT events could be cached in area concentrator; then forward when network traffic permits n Area concentrator inspects message header and if emergency detected forwards message immediately with potential auto retransmissions n

Messaging Specification – Data Classes

Messaging Specification – Data Classes

Messaging Specification

Human Interface Requirements n n 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.

PCT Reference Design TOC

Questions / Comments?

Open. AMI Overview q q q 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 Open. AMI accepted CEC reference design document as a starting point

UCAIug Sponsorship of Open. AMI — 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 2005 Open. AMI | www. Open. AMI. org Slide 75

Open. AMI Task Force Mission 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 Objectives • 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 manage their energy use • Foster industry innovation, efficiency and lower cost solutions 2005 Open. AMI | www. Open. AMI. org Slide 76

Open. AMI Architecture http: //www. openami. org/ Well defined points of interoperability, interfaces, transactions, and information models 2005 Open. AMI | www. Open. AMI. org Slide 77

Utility. AMI Overview q Questions before proceeding?

Utility. AMI Overview q q 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

Utility. AMI Definition, Mission and Goal q Utility. AMI 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.

Utility. AMI Definition, Mission and Goal q Utility. AMI 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. Utility. AMI will also coordinate with other industry groups as required to efficiently carry out its mission.

Utility. AMI Definition, Mission and Goal q Utility. AMI has a goal to utilize the Utility. AMI 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 q 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.

Glossary: Definition of AMI q 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.

Glossary: Definition of AMI q 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.

Utility. AMI Tasks 1. Glossary and Common Language Framework a) b) c) A universal AMI glossary of terms and definitions A framework for technology capability evaluation A common, minimum requirements definition document 2. Modular Meter Interface – Transferred to Open. AMI 3. Security – AMI-SEC Task Force 4. Consumer Interface – HAN Task Force Policy for modular communication interfaces in meters Security issues and their relationship to business needs Policy for Customer Portal interface to customer end user appliances 5. AMI Network Interface Policy for AMI network to MDMS interfacing 6. Back Office Interface – AMI-Enterprise Task Force Policy for MDMS to enterprise back office system connectivity 7. General Issues Forum

Common Requirements Document q q q A short, easily reviewable summary of what Utility. AMI 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 Model 3) Security 4) Two-Way Communications 5) Remote Download 6) Time-of-Use Metering 7) Bi-Directional and Net Metering 8) Long-Term Data Storage 9) Remote Disconnect 10) Network Management 11) Self-healing Network 12) Home Area Network Gateway 13) Multiple Clients 14) Power Quality Measurement 15) Tamper and Theft Detection 16) Outage Detection 17) Scalability 18) Self locating

Requirements Voting Results q q 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. 2. 3. 4. American Electric Power (AEP) Con Edison Duke Energy Electric Power Research Institute (EPRI) 5. Electricitie de France (EDF) 6. First Energy 7. Hawaiian Electric Company (HECO) 8. Keyspan Energy 9. Sempra Energy (SDG&E) 10. Southern California Edison (SCE)

Status and Next Steps q Task 1 complete q q q Task 2 (modular interface) – transferred to Open. AMI Task 3 (Security) draft scoping document prepared q q q 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 Utility. AMI subtask Common requirements approved August 4, 2006 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

HAN Task Force Scope High level reference design/architecture q Utility Requirements q Information Models q Security q

Stakeholders and Collaborators Utility driven q Vendor input required q Hardware – network, devices q Associations – e. g. Zig. Bee, ZWave, Etc. q q Standards Groups

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

Questions q q After the break, we will see what Open. HAN has done to address these objectives Open Discussion

Utility. AMI Open. HAN TF Activity Summary HAN Guiding Principles, Use Cases, System Criteria

TF Operating Rules Ø Open. HAN is a TF of the Utility. AMI 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

Open. HAN Overview Ø Outline: Ø Framework introduction Ø Documentation Purpose Ø Documentation Process Ø Guiding Principles Ø Functional Characteristics Ø Use Cases Ø System Criteria Ø Next Steps - Requirements Process

AMI Opportunity for HAN Ø 1000 MW of Peak Demand Response by 20151 Ø 0. 5% Annual energy conservation effect across all customers 1 Ø 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 Grid. Wise Architecture Framework (Loosely coupled – Decomposition framework vs. Organizational interoperability view) Ø Stakeholder considerations at every level: regulators, consumers, utilities, vendors

Communication Specification Example

Security Specification Example

Open. HAN Documentation Purpose Ø Describes utility’s view of HAN Ø Establishes participation scope and scale Ø Intended audience: Ø Regulators – establish position, clarify roles and responsibility Ø Open. HAN – 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)

HAN Guiding Principles Value Proposition Guiding Principles Use Cases System Criteria Platform Independent Requirements Platform Requirements (Technology Specific)

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 Platform Independent Requirements Platform Requirements (Technology Specific)

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 Third-Party Provider Private Fixed Networks WAN/LAN 2 -way Meter RDS/FM or pager broadcast (disabled when utility network operational) • interval energy • time • billing start time • peak power • messages • acknowledgements • price signals • reliability signals 1 -way T 24 PCT Utility Owned RF-TX 1 2 -way Appliance Consumer Owned 1. e. g. , 802. 11 b, proven mesh LAN protocol, etc. Sub-meter Display Devices

Scenario B: Evolution to Multiple Gateway Model Private Fixed Networks WAN/LAN 2 -way Any interval meter or pole-top collector Utility Owned • interval energy • time • billing start time • peak power • messages • acknowledgements • price signals • reliability signals Third-Party Provider PSTN/DSL/Cable/Satellite WAN/LAN RF-TX 1 and/or Third-Party Provider 1 -way 2 -way • Special box • Internet modem • Router • Media PC • Security panel • ……. . PLC-TX² 2 -way HAN Protocols³ Zigbee Z-wave Insteon Wi-Fi EIA 709 Home. Plug Bluetooth 2 -way T 24 PCT HAN access using expansion port 2 -way Broadband TV, music 1. e. g. , 802. 11 b, proven mesh LAN protocol, etc. 2. To be determined 3. Up to 45 active protocols worldwide Third-Party Provider RDS/FM or pager broadcast 2 -way Any gateway (protocol xfr) 2 -way Third-Party Provider 2 -way Consumer Owned 2 -way Sub-meter Appliances Display Devices

Scenario C: 3 rd Party Communication Channel/Gateways Only (Out of Scope for Open. HAN) • interval energy • time • billing start time • peak power • messages • acknowledgements • price signals • reliability signals Third-Party Provider utility. com Third-Party Provider PSTN/DSL/Cable/Satellite WAN/LAN Third-Party Provider RDS/FM or pager broadcast 2 -way Private Fixed Networks 2 WAN/LAN 2 -way Any interval meter Any gateway (protocol xfr) 1 -way 2 -way • Special box • Internet modem • Router • Media PC • Security panel • ……. . Utility Owned HAN Protocols³ Zigbee Z-wave Insteon Wi-Fi EIA 709 Home. Plug Bluetooth 2 -way T 24 PCT HAN access using expansion port 2 -way Broadband TV, music 1. Utility information to/from utility network 2. Up to 45 active protocols worldwide Third-Party Provider 2 -way Consumer Owned 2 -way Other Appliances Display Devices

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 k. Wh 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 Notes Ø Dependent on Submetering use case Ø Energy Supplying Unit (ESU) can be an energy storage device (e. g. , electric vehicle battery) or an energy generation device (e. g. , photovoltaic array or backup generator). Ø Assumes that the Energy Supplying Unit (ESU) already contains energy

User Information Ø Covers utility initiated messages and electric usage updates via an In Home Display (IHD) – does not cover other internal HAN display functions Ø Assumptions and Notes Ø Rapid updates to any IHD does not restrict AMI or other utility functionalities Ø The IHD is either pre-programmed to respond appropriately to price, consumption, load or event messages and/or the customer has manually programmed the IHD Ø The IHD indicates the status of the communication link with the Utility AMI gateway

Submetering Ø Covers the measurement of other metering devices within the HAN Ø Assumptions and Notes: Ø The AMI system supports Sub meter device-specific, consumerspecific 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 submetering, 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.

Open. HAN Use Cases Ø Ratified unanimously by the six utilities in attendance 8/15/2007 ØAEP ØConsumers Energy ØEDF ØPG&E ØSCE ØSDG&E Ø Other utilities may ratify after review

HAN System Criteria and Functional Characteristics Value Proposition Guiding Principles Use Cases System Criteria Platform Independent Requirements Platform Requirements (Technology Specific)

HAN Functional Characteristics and System Criteria

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 Ø Ø Measurement & Monitoring - Applications that provide internal data & status Ø Ø Ø Distributed generation (DG) - Local energy input/output (k. Wh, k. W, 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. Ø Ø Ø Ø 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 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 CO 2 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 System Criteria Platform Independent Requirements Platform Requirements (Technology Specific)

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 Open. HAN TF Vetting Process

Requirements Process Proposal (continued)

Next Steps Ø Develop Open. HAN 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 Open. AMI and Utility. AMI working on specific technology mappings and applications guidelines (e. g. information models, security profiles, communication profile mappings)

General Discussion q We need feedback q Does the process make sense? q How do you see the HAN evolving? q What industry do you see driving the HAN? q How do multiple HAN’s co-exist and cooperate – or stay out of each others way? q Is what we have done so far useful? q What use cases (scenarios) are missing?

AMI / DRI Security q Questions before proceeding?

AMI Security – Statement of Objectives q “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? q The answer to this revolves around two key issues: Definition of Critical Infrastructure q Placement of Electronic Security Perimeter q

Do the NERC CIP Standards Apply to AMI? q q 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: q R 1. 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 q Questions before proceeding?

California Title 24 l l l Building Code Update for 2008 Requires installation of PCTs for new construction Purpose is to ensure a baseline resource for demand response Utilizes a California wide communications infrastructure IOUs can utilize their own AMI network instead

PCT Security l Programmable Communicating Thermostat ¢ Dovetails into AMI ¢ Designed to work “stand-alone” (one-way communications) ¢ Mandated by law in California l Issues ¢ Needs to work to enable Demand-Response ¢ Must authenticate broadcast signals ¢ Distributed through variety of channels ¢ Resource-constrained platform

Fundamental Strategic Objectives l Resistance ¢ Protect l Resilience ¢ Limit l Access and Control Damage and Loss Recovery ¢ Regain Confidence in Safe, Reliable Operation

Assumptions l Human Factors ¢ l Practical Recovery ¢ l 1) Authentication, 2) Message Integrity Distribution Channels ¢ l Replacement / Repair Costs, Negative Publicity Security Priorities ¢ l Organizational Lapses, Honest Error, Malice Manufacturers, Utilities, Retail Channels Feedback ¢ Error Codes, Serial/Model #, Customer Info, Date/Time/Loc

Risk Management Approach l Assets ¢ l Threats ¢ l Frequency x Severity Mapping ¢ l Possible Source, Intent, Strength Vulnerabilities ¢ l Value, Sensitivity Aspect (C-I-A) Threats through Vulnerabilities to Assets Mitigation ¢ Reduce, Transfer, Accept

Possible Attacks Application Layer l Sudden Load l Recall Authentic Signal l Load Shed l Software Download l False Acknowledgement l False Time Synch l False Display Messages l Gaming the System Transport Layer l Control of Head-End Radio System l Do. S Head-End l Interception of Wireless Message Physical Layer l Signal Jamming / False Messages ¢ ¢ l Ground Station or Vehicle Balloon / Aircraft Customer Disables Thermostat Antenna

Possible Attacks

Non-Cryptographic Mitigation Methods l Principles ¢ Time As Ally – Slow the Attack ¢ Limit Allowable Behavior ¢ Detection As Well As Prevention l Business Logic ¢ Acceptable Commands, Random Delay On Cancel, Hard Limits, Time Synch l Detection and Environment ¢ IDS, Heartbeat, Historical Data, Tamper Detection

Non-Cryptographic Mitigation Methods

Message Content l l Timestamp Message Identifier ¢ Use cryptographic nonce principles ¢ PCT remembers most IDs used Valid range only slightly larger than PCT memory l Difficult to guess unused ID l l Timestamp + ID Unique Content ¢ Regardless of instruction ¢ Complimented by use of an HMAC

Cryptographic Mitigation Approaches l Secret Sharing (a. k. a. “Key Splitting”) l Asymmetric Cryptography

Registration Use Case Installer retrieves random number from PCT. Installer contacts System Operator via out-of-band channel. Installer relays PCT random number to System Operator relays PCT random number to System Owner performs two XOR operations: 1. 2. 3. 4. 5. l l 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. With PCT random number and System Owner’s primary public key With PCT random number and System Owner’s backup public key. System Owner sends results of XOR operations to System Operator performs XOR operation with PCT random number and System Operator’s public key. System Operator transmits registration signal including the labeled results of all three XOR operations to PCT performs XOR operation with its random number and each of the three result numbers received via registration signal, recovering three labeled public keys. System Owner encrypts activation message with System Owner’s primary public key. System Owner sends (encrypted) activation message to System Operator encrypts activation message with System Operator’s private key. System Operator transmits (double encrypted) activation message to PCT decrypts activation message: first with System Operator’s public key; second with System Owner’s primary public key. PCT activates.

Key Management l Sole purpose of Backup key would be to distribute new Primary key. l Operator keys may represent regions, substations, territories, etc…

Remaining Issues l Finalize Algorithms ¢ ECC Recommended ¢ Hashing, Key Wrapping Still To Be Determined Finalize Number of Levels, Groups of Keys l Determine Frequency of Time Signal / Heartbeat Message l

Final Discussion l What have we missed? l You can contribute ¢ Utility. AMI – General Requirements ¢ Open. HAN ¢ AMI-SEC – HAN Requirements – Security Geeks Only ¢ AMI-Enterprise – SOA for MDMS / CIS ¢ Open. AMI – Vendors building stuff ¢ Open. PCT – Title 24 implementation

Contact Us For any additional information, please do not hesitate to contact us Erich W. Gunther Ener. Nex Corporation Phone: 865 -691 -5540 ext. 114 [email protected] com www. enernex. com http: //www. utilityami. org/ http: //sharepoint. ucausersgroup. org/openami/ http: //sharepoint. ucausersgroup. org/openhan/ http: //sharepoint. ucausersgroup. org/utilityami/amisec/