1. Dec 20071 UtilityAMI OpenHAN TF Requirements Working Group Specification Briefing January 2008

2. Dec 20072 Introduction  Purpose:  Information sharing (level setting)  Validate approach  Drive technology implementations  Establish participation and responsibility  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  Time management: cuts down on vendor clarification meetings and phone calls  Outline:  Introduction  Documentation process  Guiding principles  Use Cases  Architecture  Requirements  Requirements Mapping

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

4. Dec 20074 Documentation Process (Ratified)

5. Dec 20075 Specification Outline

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

7. Dec 20077 HAN Guiding Principles 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

8. Dec 20078 HAN Use Cases Value Proposition Guiding Principles Use Cases Platform Independent Requirements and Architecture Considerations Platform Requirements (Technology Specific) System Criteria

9. Dec 20079 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)

10. Dec 200710 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  HAN Metering

11. Dec 200711 Platform Independent Requirements Value Proposition Guiding Principles Use Cases Platform Independent Requirements and Architecture Considerations Platform Requirements (Technology Specific) System Criteria

12. Dec 200712 Requirements Overview  Requirements are platform independent  Requirement are to products applied via device mappings (Appendix)  Special class of requirements for an AMI gateway (See Mappings)  Two types of compliance  Technology/alliance – application and communication compliance (e.g., message structures)  Vendor/product – compliant with device mapping requirements

13. Dec 200713 HAN Requirements Organization and System Criteria

14. Dec 200714 HAN Requirements Organization and Use Cases

15. Dec 200715 Requirements Example Context: Applications that respond to control commands from the utility or authorized third parties. Commands typically tell a device to turn ON/OFF at configurable time intervals or thresholds or enter into an energy saving mode. Requirements:  App.Control.1 HAN Device shall accept control signals from the utility.  App.Control.2 HAN Device shall respond to requests to cease operational state (e.g., open contact).  App.Control.3 HAN Device shall respond to requests to resume operational state (e.g., close contact).  App.Control.4 HAN Device shall acknowledge receipt of control signal.  App.Control.5 HAN Device shall acknowledge execution of control request.  App.Control.6 HAN Device shall acknowledge execution failure of request (i.e., exceptions).  App.Control.7 HAN Device shall signal any consumer-initiated overrides.

16. Dec 200716 Device Mappings  Tool for applying the specification  Device mappings are logical  Actual Product offerings may include several logical devices  Legend: Basic (B), Enhanced (E), Not Applicable (NA), Optional (O)  Optional Requirements – suggestion to vendor to examine capability  Logical Devices include:  Energy Services Interface  PCT  Display  EMS  Load Control  HAN Electric Meter  HAN Meter (non-electric)  Smart Appliance

17. Dec 200717 Device Mapping Example Requ. IDOpenHAN System Requirements Energy Services Interface PCTDisplayEMS Load Control HAN Electric Meter HAN Meter (non- electric) Smart Applianc e App.Control.1 HAN Device shall accept control signals from the Utility.NABBBBBBB App.Control.2 HAN Device shall respond to requests to cease operational state (e.g., open contact).NAB BB E App.Control.3 HAN Device shall respond to requests to resume operational state (e.g., close contact).NAB BB E App.Control.4 HAN Device shall acknowledge receipt of control signal.NAB BB E App.Control.5 HAN Device shall acknowledge execution of control request.NAB BE O App.Control.6 HAN Device shall acknowledge execution failure of request (i.e., exceptions).NAE EE O App.Control.7 HAN Device shall signal any consumer-initiated overrides.NAB BE O App.Control.8 HAN Device shall respond to request to cease operation state at a specific time.NAB BE O

18. Dec 200718 Architecture Considerations  The architectural consideration section is not binding  Provided for context  Sections include:  Utility Interface  Device Ownership  Public Broadcast Interface  Broadcast ID (e.g., Utility ID, SSID)  Current Price (e.g., $0.XX/kWhr)  Relative Price (e.g., high, medium, low)  Message Expiration Time (e.g., 1 – 1440 minutes)  Rate Descriptor (e.g., residential, commercial, etc.)  Severity of Event Description (e.g., Stage 1, 2, 3)  Integrity check (e.g., CRC)  Utility Secured Interface  Consumer Devices  Utility Devices  Cohabitation  Deregulated Utilities  Four Scenarios given as examples

19. Dec 200719 Interface

20. Dec 200720 Scenario One (Inception)

21. Dec 200721 Scenario Two (Cohabitation)

22. Dec 200722 Scenario Three (Mature)

23. Dec 200723 Scenario Four (Deregulated)

24. Dec 200724 Next Steps  Comment Resolution  Comments need to include page number and line number  Include suggested change  Comments Deadline (Feb 9 th ?)  Final Publishing 1.0 (Feb 22 nd )  HAN Interoperability  CIM Discussions  Application Level Standardization  Splinter Groups?