OpenHAN SRS v1.95 Overview June 8, 2010

2 OpenHAN SRS v Introduction  OpenHAN area of focus within the NIST conceptual model

3 OpenHAN SRS v Introduction, continued  Purpose  Define the system requirements for an open standard Home Area Network system  Promote open standards-based HANs that are interoperable  Provides the vendor community with a common set of principles and requirements around which to build products  Ensures reliable and sustainable HAN platforms  Supports various energy policies in a variety of states, provinces, and countries  Empower consumers to manage their electricity consumption by giving them the information and control they need to make decisions on their energy use and to effectively control their energy consumption

4 OpenHAN SRS v Introduction, continued  Purpose, continued The audiences for the OpenHAN SRS are:  Utilities considering deploying AMI systems that interact with HANs  Vendors that make AMI systems for Utilities that interact with HANs  Vendors that make consumer products (e.g. PCT,EMS, load control switches, in-home displays, smart appliances, PEV, DER, etc.)  Service Providers developing smart grid enabled programs for consumers (e.g. demand response, energy management, pre-pay, PEV programs, distributed energy resources, etc.)  Policy makers looking to understand how Utility AMI deployments benefit consumers  Industry alliances and standards organizations  NIST Smart Grid Interoperability Panel (SGIP) activities (e.g. Smart Grid Architectural Committee (SGAC), Cyber Security Working Group (CSWG), Smart Grid Testing and Certification Committee (SGTCC), etc.)

5 OpenHAN SRS v Introduction, continued  Scope, Definitions, Other Considerations and References  Provides platform-independent requirements for HAN devices regardless of device ownership  Not limited to the residential premise, although the residential consumer has the most to gain from the OpenHAN SRS  Provides an overview of the regulatory, political, and legislative environment that influenced the development of the OpenHAN SRS  Security in the HAN Environment  Two-way HAN communication is a new technology being introduced to the electric power grid  The proper security measures need to be in place to reduce the risk of intrusion, eavesdropping, and the transmittal unwanted content  OpenHAN TF in conjunction with SG Security WG evaluated the potential impact of a security compromise to the HAN  OpenHAN TF reviewed the NISTIR 7628 recommended security requirements for the HAN interface to identify any gaps

6 OpenHAN SRS v Overall Description  Guiding Principles  Capabilities 1.Secure Two-way Communication Between HAN Devices and Service Provider(s) 2.Supports load control integration 3.The AMI meter provides the HAN with direct access to Consumer-specific usage data 4.Provides a growth platform for future products which leverage the HAN and meter data 5.Supports three types of messaging: Public, Consumer-Specific, and Control 6.Supports end-use metering and other utility meters 7.Supports distributed energy resources  Assumptions 8.Consumer owns the HAN 9.HAN devices present additional security considerations 10.The HAN is enabled by open and interoperable standards

7 OpenHAN SRS v Overall Description, continued  Architectural Considerations  OpenHAN applies from the edge of the AMI System, where the Energy Services Interface (ESI) resides, to all relevant HAN Devices in the home  Energy Services Interface (ESI) o An interface which enables communication between authorized parties and HAN devices that are registered to it o There may be more than one ESI in the premise o Utility ESI – provides interface between the Utility AMI network and HAN devices o Other ESI – provides interface between other communication media (e.g. internet, cell phone, EMS, etc.) and HAN devices registered to it

8 OpenHAN SRS v Overall Description, continued  Architectural Considerations, continued  Commissioning, Registration, Enrollment o Commissioning is the process by which a HAN device obtains access to a specific physical network and allows the device to be discovered on that network o Registration is the process by which a Commissioned HAN device is authorized to communicate on a logical network by exchanging security credentials with an ESI o Enrollment is the process by which a Consumer enrolls a HAN device in a Service Provider program (e.g. demand response, energy management, PEV program, etc.)

9 OpenHAN SRS v1.95

10 OpenHAN SRS v Overall Description, continued  Architectural Considerations, continued  OpenHAN SRS is agnostic to device ownership  Some HAN devices may reside on a 3rd party network and the Utility ESI  OpenHAN SRS is agnostic to electric market structure and may be used in integrated utility markets as well as consumer choice electric markets  There may be multiple communication paths into the HAN (e.g. Utility AMI, internet, cell phone network, EMS, etc.)  OpenHAN SRS addresses the following special applications o PEV including the Energy Vehicle Supply Equipment (EVSE) and End-use Measurement Device (EUMD) o Energy Management System (EMS) o Distributed Energy Resources (DER)

11 OpenHAN SRS v OpenHAN System Requirements  Requirements Mapping to Logical Devices  Provides guidance to Service Providers and vendors  For reference only and should not limit the needs of Service Providers or vender innovation  Mapping Categories o BC or Basic Commissioning – Minimum requirement for the Commissioning process. These requirements are mandatory and must be included to support the process of Commissioning a HAN device on the HAN. o BC or Basic Registration - Minimum requirement for the Registration process. These requirements are mandatory and must be included to support the process of Registering a HAN device on the ESI. o BF or Basic Functionality – Minimum requirement that the OpenHAN TF recommends is needed to support the basic functionality of the logical HAN device. o O or Optional – An optional requirement that may be included to support a Service Provider program or allow a vendor to differentiate their product. o NA or Not Applicable - This requirement is not applicable to this logical HAN Device.

12 OpenHAN SRS v OpenHAN System Requirements, continued  Requirements Mapping to Logical Devices, continued  Logical Devices  Mapping table located after each requirement section except for the security requirements which will be mapped to each requirement rather than to a logical device

13 OpenHAN SRS v OpenHAN System Requirements, continued  Requirements Framework and Assumptions  Application Requirements  Control applications respond to control signals  Measurement and Monitor applications provide internal data and status  Processing applications consume, process, and act on external and internal data  Human Machine Interface (HMI) provides Consumers a means to provide input into an application or to view information from an application  Communication Requirements  Commissioning is the network process of adding a HAN device on the HAN to allow the device to communicate with other devices and involves network scanning, selection, admission, and configuration  Control of a node involving self-organization, path selection, mitigation

14 OpenHAN SRS v OpenHAN System Requirements, continued  Security Requirements  Access Controls and Confidentiality address data protection for data-at- rest and data-in-transit  Registration is the network process to authenticate and authorize HAN device participation with an ESI and includes initialization, authentication, correlation, authorization, and de-register  Enrollment is the process by which a Consumer enrolls a HAN device in a Service Provider’s program (e.g. demand response, energy management, pre-pay, PEV programs, distributed generation, pricing, messaging, etc.) and gives certain rights to the Service Provider to communicate with their HAN device  Integrity preserves the HAN operating environment through resistance and recovery  Accountability will allow for monitoring malicious activities through audit and non-repudiation

15 OpenHAN SRS v OpenHAN System Requirements, continued  Performance Requirements ensure applications or other factors do not limit the performance of the system, which is dependent upon availability, reliability, maintainability, scalability, upgradeability, quality and latency  Operations, Maintenance, and Logistics Requirements  Manufacturing and Distribution - Vendor’s pre-installation activities including pre-Commissioning settings, application configuration, labeling, support for multiple distribution channels  Installation – Documentation for the physical placement of the device and support systems  Manage, Maintain – ensure HAN device diagnostic, management and trouble shooting capabilities including alarming, logging, testing, device reset, and monitoring

16 OpenHAN SRS v Appendices  Use Cases  Industry use cases reviewed to identify any OpenHAN SRS gaps o ZigBee+HomePlug SEP MRD o SAE J2836/1™ J2836/2™ and J2836/3™ Use Cases o NAESB Draft Requirements Specifications for NIST PAP03, PAP04, and PAP09 o EIS Alliance Customer Domain Use Cases v1.0 o CEC Requirements Engineering for the Advance Metering Infrastructure and the Home Automation Network (AMI-HAN) interface – February 2008 o AHAM Smart Grid White Paper o DER Contribution to OpenHAN; EPRI/DOE PV/Storage Communication Project o Summary of Use Cases: For Demand Response Appliances Interface (EPRI Adapters)

17 OpenHAN SRS v Appendices  Use Cases, continued  OpenHAN TF use cases o Load and Energy Management o User Information o In-premises Metering o System Configuration and Management o HAN Security Considerations o Considers the potential impact to HAN stakeholders due to a security compromise in the HAN o Scope of compromise o Singular device within a single HAN o Multiple devices within a single HAN, up to and including all devices within a single HAN o Multiple devices within multiple HANs (single neighborhood scale) o Large number of HANs (multiple neighborhood)

18 Questions? Join OpenHAN TF OpenHAN reflector: Web meeting information: Provided via to all members of OpenHAN reflector Announced on the OpenSG sharepoint in the OpenHAN calendar OpenHAN documents: Located in Shared Documents/OpenHAN 2.0 folder