1. UtilityAMI HAN Task Force July 2, 2007

2. Agenda • Introductions / Background • Overview of HAN Framework - 20 minutes • California IOU Presentation/Discussion on Specific Requirements - 60 - 90 minutes • Other utility presentations / contributions • Report on use case development progress • General Discussion • Lunch - end of general meeting • Working meeting to develop use cases and requirements draft documents • 3 PM - 5 PM - Energy Technology Center Visit

3. 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

4. TF Scope and Deliverables • Scope – Requirements for utility applications that utilize a home area network interface implemented in utility owned equipment • Assumptions • Technology and platform independent – well defined interfaces • Not addressing any particular regulatory requirements • Non prescriptive – requirements only apply if a utility is implementing a Home Area Network Interface in a meter – if you have a HAN, then these are the requirements • Deliverables • Use Cases • Tool to generate / validate requirements • OpenAMI to maintain • Common Requirements Document • To give vendors guidance • For other organizations to develop details

5. Next Steps from Last Meeting • Publish CA IOU vision statement • Develop OpenHAN comprehensive HAN use cases • Develop OpenHAN platform independent requirements • Develop UtilityAMI platform independent architectural views for AMI and HAN • Continue to share information with technology communities (i.e., vendors, alliances)

6. Appliance Sub-meter Display Devices Architectural View A: Meter as Gateway Third-Party Provider RDS/FM or pager broadcast (disabled when utility network operational) • interval energy • time • billing start time • peak power • messages • acknowledgements • price signals • reliability signals Private Fixed Networks WAN/LAN 2-way 1-way Meter T24 PCT Utility Owned 2-way RF-TX1 Consumer Owned • e.g., 802.11b, proven mesh LAN protocol, etc.

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

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

9. 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

10. Use Case Notes from Last Meeting • SCE and SDG&E will submit use cases • User to display device interaction scenario – C2, C3 • Prepay, service request/info, usage display • AMI system to EMS scenario • Reliability response scenario – D1 • No opt-in / opt-out • Price response scenario – C1 • Opt-in / opt-out – California -> must be part of a program • Override button scenario • HAN management – Derivation of I2 – and Title24 • Device provisioning - – initial and update • Security credential establishment • Heartbeat, Diagnostics • Firmware upgrade – I1 • New piece for HAN • Customer HAN evolution management • Customer generation scenarios • Net metering, EV interface, PV, etc. – V2G • Security threat scenarios – Title 24 work

11. CA IOU HAN TF Contribution • Scope and vision for utility implemented HAN’s

12. Other Utility Contributions • Consumers Energy - Connectivity Scenarios • Case 1 - single PCT, single meter - fairly straightforward model. • Case 2 - two PCTs, single meter - again fairly straightforward and fairly common (I believe Wayne will cite that approximately 40% of homes are dual-zone). • Case 3 - starts to get a little crazy. This model represents more of an urban setting. Homes are close together and there is no guarantee that a specific PCT will talk to a specific meter, or even collector for that matter. The first time that the PCTs for the home presented in the midst of this model are "unified" are back at the MDMS. • Case 4 - this is used to represent a situation where you have a multi-unit building that could have PCTs for each unit and a bank of meters in the basement.

13. PCT Connectivity Scenarios 1. 2. 4. 3.

14. Questions • Strength of signal connectivity, a given PCT may connect to one gateway today, a different one tomorrow. What problems does this present? • If I have tied a PCT to a given meter, what happens when I swap out that meter? • Will a given configuration limit what services the utility can offer to a customer and does this create a communication issue? • What is the best way to incent consumer behavior? Do they need usage information at the PCT, or is having it at the meter "good enough", with the option to provide detailed information the next day via the web a better alternative? Is information the primary driver, is it money, or is it a combination of both? • A usability concern in that consumers will have a "light switch" mentality when it comes to use of ease. They have an expectation that when they flip a switch the light comes on, how to we manage this expectation when connecting, validating, and securing a PCT to "our" network. • Some of these questions get complicated if we need to do this "real time" versus a model where price signals (red, yellow, green) are sent to the PCT and more detailed information is presented either on the meter, or via the web the next day, or some greater than "real time" increment

15. General Discussion • How to proceed? • What defines completion? • Other work • PCT Task Force – Title 24 Profiles • HAN Security Task Force

16. Working Session • Use Case Refinement • Document Outline • Write the requirements

17. HAN Use Cases – Updates to SCE/OpenAMI Use Cases • C1 - Customer reduces their Usage in response to Pricing or Voluntary Load Reduction Events. • OPENAMI USE CASE: 5 • C4 - External Clients use the AMI to interact with devices at Customer Site • D1 - Distribution Operations curtails customer load for grid management • I1 - Utility installs, provisions and configures the AMI [and Utility HAN] system • I3 - Utility Upgrades AMI system to Address Future Requirements