Erich W. Gunther, P.E. Chairman and CTO EnerNex Corporation Chairman UtilityAMI, OpenHAN, CA Title 24 PCT Reference Design Task Force.

Erich W. Gunther, P.E. Chairman and CTO EnerNex Corporation erich@enernex.com Chairman UtilityAMI, OpenHAN, CA Title 24 PCT Reference Design Task Force Home Area Network Workshop

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?

Consumer Portal FAQ Copyright © EPRI 2005 – 5 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 – 6 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 – 7 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 – 8 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 – 9 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.comwww.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 – 10 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 – 11 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 – 12 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 – 13 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 – 16 What could portals do? 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

Consumer Portal FAQ Copyright © EPRI 2005 – 17 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 – 18 What could portals do? 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

Consumer Portal FAQ Copyright © EPRI 2005 – 19 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” Monitor and optimize power quality more accurately Monitor and control distributed generation Minimize system losses

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

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

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

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

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

 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 w Market power (Enron, et al) w Aging fossil fuel plants (pollution) w Flaws in deregulation (AB 1890) w 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 “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/

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 Scalability w Interoperability w Facilitating Innovation (cheaper, better, faster) w 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 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 w ISO issues command in different ways to different IOU’s w Each IOU sends ELC signal to their subscribed loads using different methods with varying latencies and feedback  Future w Available ELC providers known to ISO through a common information system including stats on available ELC and expected response magnitude and delay w ISO broadcasts ELC signal using a single, standard method to all IOU’s, ESP’s, LSE’s, and other providers w Each provider relays ELC signal using standard interface to all subscribers w Subscriber response is confirmed, logged, and reliability statistics are updated and made available immediately to the ISO w Regulators are able to audit program effectiveness, system capacity and actual performance

CALIFORNIA ENERGY COMMISSION Strawman Reference Design  Zones of information exchange w Inside is a domain of open systems information exchange w 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

Interfaces and Transactions  DR information exchange infrastructure is typically specified in terms of interfaces and transactions. 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. w 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 Information exchange will be required between several organizations and systems w Numerous applications that create and consume information will exist

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

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

Basic (Mandatory) HVDC Interface

Advanced (Optional) Interface

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 Modes  Price Events  Emergency Events

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

Addressing Scheme Enables Regional or PCT Level Filtering  Place holder for value added information to facilitate PCT side filtering Two Levels of PCT Operational Status Visual Indication Possible  Underlying Physical Communication Layer e.g. – carrier heartbeat  Derived 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 effect  Explicit price Price event message definition  Start 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 Time  Advance Scheduling  Reliability Selections Change Temperature Set Temperature

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 Area concentrator inspects message header and if emergency detected forwards message immediately with potential auto retransmissions

Messaging Specification – Data Classes

Messaging Specification

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.

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

2005 OpenAMI | www.OpenAMI.org Slide 76 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 modelObjectives 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

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

 Questions before proceeding? 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

UtilityAMI Definition, 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 Definition, Mission and Goal  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 Definition, Mission and Goal  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.

Glossary: Definition of AMI  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  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 Framework a)A universal AMI glossary of terms and definitions b)A framework for technology capability evaluation c)A common, minimum requirements definition document 2.Modular Meter Interface – Transferred to OpenAMI Policy for modular communication interfaces in meters 3.Security – AMI-SEC Task Force Security issues and their relationship to business needs 4.Consumer Interface – HAN Task Force 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  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 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  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 Edison 3.Duke Energy 4.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  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 subtaskhttp://www.sce.com/ami/  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

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 TF Activity 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 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 2015 1  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 GridWise 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

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)

HAN Guiding Principles Value Proposition Guiding Principles Use Cases Platform Independent Requirements Platform Requirements (Technology Specific) 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 Platform Independent Requirements Platform Requirements (Technology Specific) 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 Networks WAN/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-TX 1 Third-Party Provider

Scenario B: Evolution to Multiple Gateway Model Utility Owned Consumer Owned Private Fixed Networks WAN/LAN Any interval meter or pole-top collector PSTN/DSL/Cable/Satellite WAN/LAN 2-way Any gateway (protocol xfr) Special box Internet modem Router Media PC Security panel …….. HAN Protocols ³ Zigbee Z-wave Insteon Wi-Fi EIA709 HomePlug Bluetooth 2-way T24 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 determined 3.Up to 45 active protocols worldwide Broadband TV, music 2-way interval energy time billing start time peak power messages acknowledgements price signals reliability signals RF-TX 1 PLC-TX ² and/or Third-Party Provider 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 Networks 2 WAN/LAN Any interval meter PSTN/DSL/Cable/Satellite WAN/LAN 2-way Any gateway (protocol xfr) Special box Internet modem Router Media PC Security panel …….. HAN Protocols ³ Zigbee Z-wave Insteon Wi-Fi EIA709 HomePlug Bluetooth 2-way T24 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 network 2.Up to 45 active protocols worldwide Broadband TV, music 2-way interval energy time billing start time peak power messages acknowledgements price signals reliability signals Third-Party Provider 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 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, 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 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.

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

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

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?

 Questions before proceeding? 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.

 Questions before proceeding? Title 24 PCT Security

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

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

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

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

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

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

Possible Attacks

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

Non-Cryptographic Mitigation Methods

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

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

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

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

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

Final Discussion What have we missed? What have we missed? You can contribute You can contribute UtilityAMI – General Requirements OpenHAN – HAN Requirements AMI-SEC – Security Geeks Only AMI-Enterprise – SOA for MDMS / CIS OpenAMI – Vendors building stuff OpenPCT – 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 erich@enernex.com erich@enernex.com www.enernex.com 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 Chairman UtilityAMI, OpenHAN, CA Title 24 PCT Reference Design Task Force.

Similar presentations

Presentation on theme: "Erich W. Gunther, P.E. Chairman and CTO EnerNex Corporation Chairman UtilityAMI, OpenHAN, CA Title 24 PCT Reference Design Task Force."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Erich W. Gunther, P.E. Chairman and CTO EnerNex Corporation Chairman UtilityAMI, OpenHAN, CA Title 24 PCT Reference Design Task Force.

Similar presentations

Presentation on theme: "Erich W. Gunther, P.E. Chairman and CTO EnerNex Corporation Chairman UtilityAMI, OpenHAN, CA Title 24 PCT Reference Design Task Force."— Presentation transcript:

Similar presentations

About project

Feedback