1 / 89

Utility Industry AMI Requirements Development

Utility Industry AMI Requirements Development. Erich W. Gunther UtilityAMI Chairman/Facilitator Chairman/CTO – EnerNex Corporation erich@enernex.com. Agenda. Introductions – Membership - Overview of organization within the UCAIug

Download Presentation

Utility Industry AMI Requirements Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Utility Industry AMIRequirements Development Erich W. Gunther UtilityAMI Chairman/Facilitator Chairman/CTO – EnerNex Corporation erich@enernex.com

  2. Agenda • Introductions – Membership - Overview of organization within the UCAIug • Review scope, work plan, accomplishments, and what remains to be done – new member orientation • Task force reports • AMI-Enterprise – Wayne Longcore • OpenHAN – Erich Gunther • AMI-SEC – Darren Highfill • Liaison reports • UtiliSec / ASAP – Darren Highfill • OpenAMI – Craig Rodine or designate • IEEE PES IGCC – Erich Gunther / Doug Houseman • Discussion of new task force(s) and activities • Marketing decks • AMI-Network – only remaining task - looking for a chairman • Information exchange and data repositories • Other AMI application requirements needs • Other business, Next Meetings (GridWeek, Grid Interop) • Adjourn – followed by OpenHAN TF and HAN SRS Overview

  3. Membership • Join the UCAIug at: • http://www.ucaiug.org/Pages/join.aspx • Get web site user ID at: • http://osgug.ucaiug.org/default.aspx • Join mailing lists at: • http://listserv.enernex.com/archives/index.html • List Subscribers as of August 21, 2008 • AMI Enterprise Task Force (61 subscribers) • AMI Security (127 subscribers) • UtilityAMI Guests (75 subscribers) • UtilityAMI HAN TF (152 subscribers) • UtilityAMI Members (90 subscribers)

  4. UCAIug Organization • OpenDR => OpenSG

  5. OpenSG Organization OpenSGSubcommittee UtilityAMI WG OpenAMI WG UtiliSec WG Requests for specific technologydevelopment and transfer of use casesfor ongoing support and evolution AMI-Sec TF OpenHAN TF AMI-Enterprise TF

  6. UtilityAMIDefinition, Mission and Goal • UtilityAMI is …A forum to define serviceability, security and interoperability guidelines for advanced metering infrastructure (AMI) and demand responsive infrastructure (DRI) from a utility / energy service provider perspective.

  7. UtilityAMIDefinition, Mission and Goal • UtilityAMI will develop high level policy statements that can be used to facilitate efficient requirements and specification development using a common language that minimizes confusion and misunderstanding between utilities and vendors. UtilityAMI will also coordinate with other industry groups as required to efficiently carry out its mission.

  8. UtilityAMIDefinition, Mission and Goal • UtilityAMI has a goal to utilize the UtilityAMI work products to influence the vendor community to produce products and services that utilities need to support their AMI and DRI initiatives.

  9. UtilityAMI Tasks • Glossary and Common Language Framework • A universal AMI glossary of terms and definitions • A framework for technology capability evaluation • A common, minimum requirements definition document • Modular Meter Interface – Transferred to OpenAMIPolicy for modular communication interfaces in meters • Security – AMI-SEC Task Force (under UtiliSEC WG)Security issues and their relationship to business needs • Consumer Interface – OpenHAN Task ForcePolicy for Customer Portal interface to customer end user appliances • AMI Network Interface – AMI-Network Task ForcePolicy for AMI network to MDMD/head end & HAN interfacing • Back Office Interface – AMI-Enterprise Task ForcePolicy for MDMS to enterprise back office system connectivity • General Issues Forum – Information Exchange     

  10. Common Requirements • A short, easily reviewable summary of what UtilityAMI members consider important for an Advanced Metering Infrastructure. • The currently foreseeable requirements for AMI systems. • AMI vendors should consider taking the information in this document into account when designing or developing AMI Systems or components • Each utility will be making its own independent decision on infrastructure and technology; consequently specific requirements will vary from utility to utility. • Document intended to provide to vendors some general guidelines as to currently desired AMI system functionality.

  11. UtilityAMI Requirements DocumentRatification Vote Results • American Electric Power (AEP) • Con Edison • Duke Energy • Electric Power Research Institute (EPRI) • Electricitie de France (EDF) • First Energy • Hawaiian Electric Company (HECO) • Keyspan Energy • Sempra Energy (SDG&E) • Southern California Edison (SCE) • Ratified Aug 4, 2006 • 10 YES votes out of 10 voting – unanimous! • The utilities voting represent more than 20 million meters in North America and nearly 60 million meters worldwide.

  12. Standard Communication Board Interface Standard Data Model Security Two-Way Communications Remote Download Time-of-Use Metering Bi-Directional and Net Metering Long-Term Data Storage Remote Disconnect Network Management Self-healing Network Home Area Network Gateway Multiple Clients Power Quality Measurement Tamper and Theft Detection Outage Detection Scalability Self locating The Requirements

  13. UtilityAMI Requirements – Page 1

  14. UtilityAMI Requirements – Page 2

  15. UtilityAMI Requirements – Page 3

  16. UtilityAMI Requirements – Page 4

  17. UtilityAMI Requirements – Page 5

  18. UtilityAMI 2008 HAN SRS • Promotes 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 • Empowers citizens with the information they need to make decisions on their energy use by enabling the vision of a home energy ecosystem

  19. AEP SCE SDG&E PG&E Detroit Edison FPL BC Hydro Entergy Consumers Energy CenterPoint Energy Oncor EDF HAN SRS Ratification Vote Unanimous – Mar 7, 2008 Endorsing Utilities: Duke EnergyReliant Energy

  20. Agenda • Introductions – Membership - Overview of organization within the UCAIug • Review scope, work plan, accomplishments, and what remains to be done – new member orientation • Task force reports • AMI-Enterprise – Wayne Longcore • OpenHAN – Erich Gunther • AMI-SEC – Darren Highfill • Liaison reports • UtiliSec / ASAP – Darren Highfill • OpenAMI – Craig Rodine or designate • IEEE PES IGCC – Erich Gunther / Doug Houseman • Discussion of new task force(s) and activities • Marketing decks • AMI-Network – only remaining task - looking for a chairman • Information exchange and data repositories • Other AMI application requirements needs • Other business, Next Meetings (GridWeek, Grid Interop) • Adjourn – followed by OpenHAN TF and HAN SRS Overview

  21. Task Force and Liaison Reports • Task force reports • AMI-Enterprise – Wayne Longcore • OpenHAN – Erich Gunther • AMI-SEC – Darren Highfill • Liaison reports • UtiliSec / ASAP – Darren Highfill • OpenAMI – Craig Rodine or designate • IEEE PES IGCC – Erich Gunther / Doug Houseman

  22. Marketing Collateral • How does the membership want to use the UtilityAMI AMI Requirements, HAN SRS and future work products? • What collateral is required? • PowerPoint presentations for various audiences • Internal for executive audience – business value • Internal for technical teams • External for industry / conferences • White papers • Who can/should produce? • Value of press releases

  23. AMI-Network TF Proposal • What are the devices and well defined points of interoperability within the field area network (FAN)? • What are the benefits of interoperability between FAN components to utilities • How do we develop requirements for them? • Network management interfaces • Monitor performance • Standardize configuration and upgrades?

  24. Information Exchange • Task 7 in our charter • Wikipedia like area for: • Glossary – we have one – needs update • AMI Project descriptions and status • Repository for: • Use cases • Business case tools and templates • Presentations

  25. Other Application Requirements • For which application areas not presently covered do you need common requirements for the purpose of influencing the AMI vendor community?

  26. Agenda • Introductions – Membership - Overview of organization within the UCAIug • Review scope, work plan, accomplishments, and what remains to be done – new member orientation • Task force reports • AMI-Enterprise – Wayne Longcore • OpenHAN – Erich Gunther • AMI-SEC – Darren Highfill • Liaison reports • UtiliSec / ASAP – Darren Highfill • OpenAMI – Craig Rodine or designate • IEEE PES IGCC – Erich Gunther / Doug Houseman • Discussion of new task force(s) and activities • Marketing decks • AMI-Network – only remaining task - looking for a chairman • Information exchange and data repositories • Other AMI application requirements needs • Other business, Next Meetings (GridWeek, Grid Interop) • Adjourn – followed by OpenHAN TF and HAN SRS Overview

  27. Break

  28. OpenHAN TF Agenda • Review scope, work plan, accomplishments • Maintenance, Marketing and Support • Document maintenance • Marketing decks • Conformance Process • Vote to approve • Discuss using UCAIug conformance committee for ongoing activity • Discussion / Vote to put TF on hiatus – job done • In depth presentation on the UtilityAMI 2008 HAN SRS • Adjourn

  29. OpenHAN Task Force • UtilityAMI established the OpenHAN Task Force to develop what is now known as the UtilityAMI 2008 Home Area Network System Requirements Specification (UtilityAMI 2008 HAN SRS). • Collaborative effort of more than ten investor-owned North American utilities serving more than 28 million electric and gas customers in 17 states and provinces

  30. OpenHAN TF Deliverables • Use Cases • RF reach scenarios • High rise scenario • User scenarios • Customer moving from one utility to another? • Common Requirements • To give vendors guidance • For other organizations to develop details • Derivative work from UtilityAMI requirements • Overarching Framework / Architecture

  31. AEP SCE SDG&E PG&E Detroit Edison FPL BC Hydro Entergy Consumers Energy CenterPoint Energy Oncor EDF HAN SRS Ratification Vote Unanimous – Mar 7, 2008 Endorsing Utilities: Duke EnergyReliant Energy

  32. OpenHAN TF Agenda • Review scope, work plan, accomplishments • Maintenance, Marketing and Support • Document maintenance • Marketing decks • Conformance Process • Vote to approve • Discuss using UCAIug conformance committee for ongoing activity • Discussion / Vote to put TF on hiatus – job done • In depth presentation on the UtilityAMI 2008 HAN SRS • Too many members don’t really know what’s in there • Adjourn

  33. Maintenance, Marketing and Support • Maintenance – Transfer to parent WG • Current draft 1.04 fixes typos, grammar, adds endorsers • The WG chair will handle further editorial fixes as they arise • The WG chair will consult the membership if more significant issues need attention • Marketing – Transfer to UCAIug • Support – Usage, conformance

  34. UtilityAMI HAN SRS Conformance - Purpose • Increased attention, interest, and product availability from the applying vendor / technology alliance membership • Increased attention, interest, and motivation from other vendors and technology alliances to the SRS and UtilityAMI goals • Easier vetting of technologies for utilities looking to procure and implement HAN Devices and systems • Easier certification of HAN Devices by motivating technology alliances to include HAN SRS compliance as part of their standard product certification process

  35. UtilityAMI HAN SRS Conformance • Concept – good housekeeping seal of approval model • Final draft has been available for review since last conference call as well as distributed to the email list • Vote to approve or table

  36. OpenHAN TF Agenda • Review scope, work plan, accomplishments • Maintenance, Marketing and Support • Document maintenance • Marketing decks • Conformance Process • Vote to approve • Discuss using UCAIug conformance committee for ongoing activity • Discussion / Vote to put TF on hiatus – job done • In depth presentation on the UtilityAMI 2008 HAN SRS • Too many members don’t really know what’s in there • Adjourn

  37. Break • Break followed by in depth presentation of the UtilityAMI 2008 HAN SRS

  38. UtilityAMI 2008 HAN SRS - Purpose • Promotes 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 • Empowers citizens with the information they need to make decisions on their energy use by enabling the vision of a home energy ecosystem

  39. UtilityAMI 2008 HAN SRS - Audience • Utilities considering deploying AMI systems with a HAN • Vendors that make AMI systems for Utilities • Vendors that make consumer products like communicating thermostats, energy management systems, load control switches, in-home displays, smart appliances, plug-in hybrid-electric vehicles, distributed generation resources, etc. • Policy makers looking to understand how Utilities are implementing directives both within and outside of their jurisdictions

  40. UtilityAMI 2008 HAN SRS – In Scope • The Guiding Principles, Use Cases, System Requirements, Architectural Drawings, and Logical Device Mappings for platform-independent HAN Devices that will be registered on a Utility’s secured communication channel – regardless of ownership of the devices. • Applies from the edge of the AMI System, where the Energy Services Interface (described in Section 1.4 and 2.2.1) resides, to all relevant HAN Devices in the home.

  41. UtilityAMI 2008 HAN SRS – Out of Scope • Does not apply to Utility systems beyond the Energy Services Interface like the AMI Meter, Utility Communications Network, and Meter Data Collection and Management Systems. • Does not extend past HAN Devices in the home that do not reside on a Utility-secured communications channel. • Examples of HAN Devices not covered in the scope of this specification are home automation, home health monitoring, and security system products.

  42. UtilityAMI 2008 HAN SRS - Use • UtilityAMI members are encouraged but not required to use and include sections of this document when procuring AMI systems with HANs and or gathering information with RFIs, RFQs, RFPs, etc.

  43. Table of Contents

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

  45. HAN Guiding Principles • Secure Two-way Communication Interface with the Meter • Supports Load Control Integration • 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 End-Use Metering • Consumer Owns the HAN • Meter-to-HAN Interface Is Based on Open Standards

  46. 1. Secure Two-way Communication Interface with the Meter • Description • Basic expectation that the AMI Meter has secure two-way communication to the Energy Services Interface (ESI), regardless of where the ESI is located. • The meter contains consumer-specific energy information and is best suited to provide the HAN with near real-time access to the data. • The ESI possesses a secure two-way communication interface for HAN Devices registered with the Utility. • Rationale • The two-way communications expectation defines the AMI-to-HAN interface and creates and enables all other capabilities within the system. • This interface may carry various data types including, sensitive data, confidential data, and control data. • Appropriate levels of security must be provided for these types of communications. • Security is critical; the security implementation protects Utility and Consumer assets while enabling the next generation of applications and capabilities.

  47. 2. Supports Load Control Integration • Description • Load control is the concept of load being deferrable. A load control device has the capability to limit the duty cycle of equipment under control. • Certain devices within the consumer’s premise (e.g., PCTs, electric pumps) can be used to shed load through direct and indirect control. • Rationale • A capability to interface and integrate with load control systems enables the Utility’s value proposition, and as such, it is critical that the capability be extended to the HAN. • In addition to load control interfacing and integration, the HAN system has several consumer enabling capabilities. • These capabilities include direct access to usage data and pricing information. • This data is generated by the meter and provides additional justification for direct meter interaction.

  48. 3. Direct Access to Usage Data • Description • Provides the HAN with direct access to Consumer-specific information and enables a new class of energy services and products. • Rationale • One of the main requirements for energy conservation is a better informed Consumer. • With more timely and detailed information at the hands of the Consumer, he will be able to make better choices about energy usage and conservation. • With direct data access, the Consumer does not need to wait until the end of the month to see how changes in his usage have affected his bill. • And with energy usage profiled in smaller increments, the Consumer can see the impact of changing his energy usage patterns.

  49. 4. Provides a Growth Platform for Future Products Which Leverage HAN and Meter Data • Description • A growth platform is typically a specifically named initiative selected by a business organization to fuel their revenue and earnings growth. • The HAN is an example of a strategic growth platform. • Strategic growth platforms are longer term initiatives where the initiative and results span multiple years. • While AMI is the catalyst for HAN information exchange, the growth platform is not limited to the Utility, but to any organization that wants to create devices or services for the HAN. • Rationale • Beyond information delivery and basic demand response the Utility expects the HAN to support the next generation of applications including distributed generation, Plug-in Hybrid Electric Vehicles, and other metering applications as the technology, information, and capabilities of the HAN matures. • By supporting open standards (see Principle 8), it is expected many vendors will be able to bring capabilities and innovation to bear on the HAN market.

  50. 5.Supports Three Types of Communications: Public Price Signaling, Consumer-Specific Signaling, and Control Signaling • Description • To support the anticipated market growth, the system must provide various types of communication: public price signaling, consumer-specific signaling, and control signaling. • Public pricing is the communication of material which is publicly available. • Consumer-specific signaling would be signaling such as that which would support a home energy management system. • Control signaling are those signals used to support load-shedding (see Principle 2). • Rationale • Each signal type is required to support the HAN as a growth platform (see Principle 4). • Each signal type warrants individual security and privacy analysis and treatment. • As such, the Utility does not take accountability and does not provide specific handling recommendations. • Consumer-specific information signaling implies a level of privacy and additional privacy measures and methods are warranted. • Control signaling for load control and direct Utility communications is a special use of the system and as such, requires robust handling methods. • This capability expectation is based on Utility accountability for safe and secure delivery of the control data.

More Related