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. Architectural View 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

7. Architectural View 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

8. Architectural View C: 3rd Party Communication Channel/Gateways Only 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

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

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