UtilityAMI OpenHAN TF

1. UtilityAMI OpenHAN TF HAN Guiding Principles, Use Cases, System Criteria Requirements Preparation Materials 15 August 2007

2. 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 • System Criteria • Next Steps (Requirements Composition)

3. 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. Documentation Process (Ratified)

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

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

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

8. 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)

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

10. 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)

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

12. 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)

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

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

15. 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 sub-metering, 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

16. OpenHAN Use Case Use Case Ratification?

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

18. HAN Functional Characteristics and System Criteria

19. 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)

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

21. 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)

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

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

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

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

26. Requirements Process Proposal (continued)

27. Next Steps • Ratify High Level System Uses (OpenHAN Use Cases) • Develop OpenHAN platform independent requirements • Ratify Requirements • Continue to share information with technology communities (i.e., vendors, alliances)