Erich W. Gunther - PowerPoint PPT Presentation

Loading...

PPT – Erich W. Gunther PowerPoint presentation | free to download - id: 239ea0-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Erich W. Gunther

Description:

AMI-Network only remaining task - looking for a chairman ... Consumer Interface OpenHAN Task Force ... Protection from impersonation, modification, replay, ... – PowerPoint PPT presentation

Number of Views:30
Avg rating:3.0/5.0
Slides: 91
Provided by: erich180
Learn more at: http://osgug.org
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Erich W. Gunther


1
Utility Industry AMI Requirements Development
  • Erich W. Gunther
  • UtilityAMI Chairman/Facilitator
  • Chairman/CTO EnerNex Corporation
  • erich_at_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 gt OpenSG

5
OpenSG Organization
OpenSG Subcommittee
UtilityAMI WG
OpenAMI WG
UtiliSec WG
Requests for specific technology development and
transfer of use cases for ongoing support and
evolution
AMI-Sec TF
OpenHAN TF
AMI-Enterprise TF
6
UtilityAMI Definition, 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
UtilityAMI Definition, 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
UtilityAMI Definition, 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
    OpenAMI Policy 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 Force Policy
    for Customer Portal interface to customer end
    user appliances
  • AMI Network Interface AMI-Network Task Force
    Policy for AMI network to MDMD/head end HAN
    interfacing
  • Back Office Interface AMI-Enterprise Task
    Force Policy 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 Document Ratification
Vote Results
  1. American Electric Power (AEP)
  2. Con Edison
  3. Duke Energy
  4. Electric Power Research Institute (EPRI)
  5. Electricitie de France (EDF)
  6. First Energy
  7. Hawaiian Electric Company (HECO)
  8. Keyspan Energy
  9. Sempra Energy (SDGE)
  10. 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
The Requirements
  1. Standard Communication Board Interface
  2. Standard Data Model
  3. Security
  4. Two-Way Communications
  5. Remote Download
  6. Time-of-Use Metering
  7. Bi-Directional and Net Metering
  8. Long-Term Data Storage
  9. Remote Disconnect
  1. Network Management
  2. Self-healing Network
  3. Home Area Network Gateway
  4. Multiple Clients
  5. Power Quality Measurement
  6. Tamper and Theft Detection
  7. Outage Detection
  8. Scalability
  9. Self locating

13
UtilityAMI Requirements Page 1
Requirement Description Benefits Expected Features
Standard Comms Board Interface A recognized open standard for the interface between a meter and its communications board. The ability to mix and match communications protocols and meters and prevent being locked into a single vendors solution. Physical and environmental specs Electrical specs Protocol specs Compatibility with existing form factors Automatic identification of comms board to meter and network
Standard Data Model A recognized open standard for the data to be exchanged between meters and the clients of metering data. The ability to use multiple vendors equipment in the same system without the cost of specialized adapters and gateways. Usable with multiple protocols Usable over multiple media Clear requirements for enforcing interoperability Guidelines for extension
Security Protection from impersonation, modification, replay, man-in-the-middle and eavesdropping attacks throughout the whole metering infrastructure using open standards. The ability to protect customers personal information in accordance with all applicable legal and regulatory requirements, including, without limitation, private usage information and billing data and prevent unauthorized actions. Encryption Authentication Credential Management Intrusion Detection Logging and auditing of all changes to data and configuration Applied in all parts of the network Applied to meter maintenance port
Two-Way Communications The ability to reliably send data to the customer site and from the customer site over the same network. The ability to receive confirmation that key commands such as curtailment requests, remote disconnects and meter program changes have been received and will be obeyed. Open standard protocols Bandwidth sufficient for remote download Easily extended Secure Does not interfere with other networks On-demand reads with the ability to get consumption, load and voltage promptly (i.e. while on the phone with a customer).
14
UtilityAMI Requirements Page 2
Requirement Description Benefits Expected Features
Remote Download The ability to remotely update the metering settings, configuration, security credentials and firmware of all devices in the AMI System. The ability to correct defects, enable new features and applications, change recording and reporting intervals, refresh security, and optimize network operation without the cost of sending personnel to the customer site. Version control Minimal impact on operation Secure Auditable
Time-of-Use Metering The meter can record what usage occurs within predefined intervals during the day. Permits utilities to provide customers with information about their own usage and to implement advanced tariffs proposed by regulators. Remotely programmable down to 5 minute intervals Remotely programmable number of rates and billing periods Time synchronization to within 1.5 minutes across multiple time zones. Time and date stamping of all measurements and logs.
Bi-Directional and Net Metering The meter can record energy flow in either direction and calculate net usage. Permits utilities to monitor and control distributed generation. Delivered and received energy consumption Demand Interval Data
Long-Term Data Storage Storage of all data within the meter for at least 45 days, a minimum of two channels Permits the network to accurately recover data after major failures. Expandable memory in meter Longer-term storage (60 days) in concentrators Concentrators only store data - may validate, but do not estimate
15
UtilityAMI Requirements Page 3
Requirement Description Benefits Expected Features
Remote Disconnect The ability to disconnect or reconnect a customers electrical service remotely. This capability may not be deployed to all meters in the AMI, but the AMI must permit it to be deployed at any customer site. Cost savings from quicker switchover of customers and from not having to send personnel to site. Improves safety for field personnel when disconnect is for lack of payment. Forced load curtailment when disconnected. Integrated in meter Switch position on display Meter transmits confirmation of commands
Network Management The ability to remotely diagnose meters and network components, and to monitor and control the status of the AMI communications network. Cost savings from not having to dispatch crews to diagnose problems and from earlier discovery of problems. Increase in overall availability of the network for more accurate billing, demand response, and reliability purposes. Remote self-tests Statistics gathering Trouble alarms sent spontaneously when necessary Remote link enable/disable Signal strength monitoring Periodic gathering of event logs Auditing of time synchronization Detailed daily reports on the status of the network and changes to its configuration.
Self-healing Network The ability of the network to detect and repair network problems automatically. Increase in overall availability of the network for more accurate billing, demand response, and power system reliability purposes. Redundant signal paths Switchover algorithms Traffic balancing Data and configuration are not lost over power failures Greater than 98 of meters successfully respond to each read
16
UtilityAMI Requirements Page 4
Requirement Description Benefits Expected Features
Home Area Network Gateway The AMI System acts as a communications gateway to devices at the customer site. Permits applications such as remote load control, monitoring and control of distributed generation, in-home display of customer usage, reading of non-energy meters, and integration with building management systems. Open standard protocol Customers can buy own equipment Secure Ability to read non-energy meters
Multiple Clients The AMI System can permit multiple authorized clients within the utility and external to the utility to access the metering data. Enables business cases for prepayment, flexible billing, online usage display, third-party aggregators, reading of other utilities meters, real-time market operations, and other flexible means of providing service. On-demand, off-cycle polling Individual addressing of meters Aggregation of meters into arbitrary groups Security, especially authentication and authorization checking of users
Power Quality Measurement Measurement and reporting of power quality information by the customer meter. Efficiency and optimization of the distribution network using highly accurate data supplied by the AMI System. Voltage min/max/profile Total Harmonic Distortion Sags/Swells/Interruptions Harmonics Phase Voltage RMS Close to real-time monitoring capability
Tamper and Theft Detection The AMI System can detect and report tampering with the meter case or theft of energy. Recovery of lost energy, repair and replacement cost reduction, cooperation with law enforcement. Inversion detection Removal detection Inactivity detection Blink counts
17
UtilityAMI Requirements Page 5
Requirement Description Benefits Expected Features
Outage Detection The AMI System can detect and report failures of meters due to power outages. Faster response and recovery from outages. Reports of outage Reports of restoration and the interval of outage Standardized open protocol interface to outage management systems Per phase outage detection
Scaleability The growth of the AMI System is not limited by the constraints of any particular component. Permits capital costs to be recovered and enables growth to be incremental rather than requiring large-scale component replacements. Modularity Distributed (non-hierarchical) processing Automatic detection of new additions Configurable resource limits Open standard interfaces
Self locating The ability to use GPS, signal strength or triangulation to geographically locate the meter In large utilities, meters may be installed but not recorded into the system. This requirement allows the utility to locate every meter either geographically or within a short distance of a geographically known device, such as a radio tower or transformer. Report latitude and longitude or nearest known communication d.
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
HAN SRS Ratification Vote Unanimous Mar 7, 2008
  • BC Hydro
  • Entergy
  • Consumers Energy
  • CenterPoint Energy
  • Oncor
  • EDF
  • AEP
  • SCE
  • SDGE
  • PGE
  • Detroit Edison
  • FPL

Endorsing Utilities Duke Energy Reliant 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
Other Business, Next Meetings
  • Informative, Tech Transfer Venues
  • GridWeek Mon, Sep 22 D.C.
  • GridInterop Wed, Nov 12 - Atlanta
  • Formal, Face-to-Face Meetings
  • Oct 21-23 Knoxville _at_ EnerNex
  • Where/when next offer to host? Somewhere warm.
  • Reference point - DistribuTech Feb 3-5 San
    Diego
  • Web Conferences
  • AMI-SEC - ongoing
  • What others needs based

27
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

28
Break
29
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

30
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

31
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

32
HAN SRS Ratification Vote Unanimous Mar 7, 2008
  • AEP
  • SCE
  • SDGE
  • PGE
  • Detroit Edison
  • FPL
  • BC Hydro
  • Entergy
  • Consumers Energy
  • CenterPoint Energy
  • Oncor
  • EDF

Endorsing Utilities Duke Energy Reliant Energy
33
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 dont really know whats in
    there
  • Adjourn

34
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

35
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

36
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

37
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 dont really know whats in
    there
  • Adjourn

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

39
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

40
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

41
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 Utilitys
    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.

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

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

44
Table of Contents
45
HAN Guiding Principles
Value Proposition
Use Cases
System Criteria
Platform Independent Requirements
Platform Requirements (Technology Specific)
46
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

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

48
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 consumers 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 Utilitys 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.

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

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

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

52
6. Supports Distributed Generation and End-Use
Metering
  • Description
  • Distributed generation systems are small-scale
    power generation technologies used to provide an
    alternative to or an enhancement of the
    traditional electric power system.
  • End-use metering is the idea that a second meter
    may be installed in the premise to support
    distributed generation production or measurement
    of discreet loads.
  • The OpenHAN and UtilityAMI architecture does not
    presume use of only electric meters.
  • The HAN ESI may also communicate with gas and
    water meters and propagate their data through the
    HAN (e.g., to an IHD) or through the AMI network
    for transfer to an appropriate entity (e.g., an
    electric utility could gather water meter
    information and pass that information to the
    water utility).
  • Rationale
  • The ability to support communication to multiple
    HAN Devices provides greater value to the
    Consumer and Utility by facilitating automation
    and reducing redundancy in the systems required
    to capture metering information.
  • As more homes and business become green it is
    anticipated that the Utility will need to support
    distributed generation sources such as solar
    panels, small wind turbines, or Plug-in Hybrid
    Electric Vehicle or Electric Vehicles that may
    discharge back into the network.
  • Non-revenue grade metering of end-use devices can
    provide consumers with additional information on
    the energy and cost associated with end-uses such
    as individual circuits, appliances, or plug loads.

53
7. Consumer Owns the HAN
  • Description
  • HAN ownership should not be confused with device
    ownership or communications accountability.
  • Consumer ownership broadly defines the rights of
    the Consumer.
  • Simply stated, the Consumer owns and controls the
    HAN.
  • Rationale
  • The Consumer for various reasons may concede
    control of her HAN.
  • Typically, this concession is part of the normal
    Utility registration process for HAN Devices.
  • That is, for certain types of communications the
    Consumer may allow Utility control.

54
8. Meter-to-HAN Interface Is Based on Open
Standards - Description
  • From the IEEE P1003.0 Committee
  • "An open system is A system that implements
    sufficient open specifications for interfaces,
    services, and supporting formats to enable
    properly engineered applications software to be
    ported across a wide range of systems with
    minimal changes, to interoperate with other
    applications on local and remote systems, and to
    interact with users in a style which facilitates
    user portability.
  • A key element of this definition is the term,
    open specification, which is defined as
  • A public specification that is maintained by an
    open, public consensus process to accommodate new
    technology over time and that is consistent with
    standards.

55
8. Meter-to-HAN Interface Is Based on Open
Standards - Rationale
  • Openness and accessibility are the keys to
    availability and prevalence.
  • It provides for a competitive market which drives
    down the price of Consumer goods.
  • Requiring vendors to use non-proprietary
    standards puts competitive pressure on vendors -
    if any single vendor offers a proprietary
    solution, this is usually a stepping stone to
    increased maintenance and support costs.
  • The Utilities are constrained by the relative
    value of the HAN and any Utility investments
    needed to readily adapt to changes in the
    technology market.
  • For this reason, this specification is written as
    platform and technology independent.

56
Questions on Guiding Principles?
57
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

58
Interface
59
Early Implementation Scenario
Utility interacts with a registered (Voluntary)
PCT. The Public Broadcast Channel interface is
used to provide price signals and grid event
messages to the Consumers unregistered Smart
Appliance. The ESI is located in the meter under
glass.
60
Customer Choice Scenario
Consumer has placed the PCT and other devices on
a third party network but chosen to register a
load control device with the Utility. The
Utility is also using the HAN for communications
to a gas meter. The Utility Public Broadcast
Channel is available but not used.
61
Mature System Scenario
Several Consumer and Utility devices, several of
which are registered with the Utility. HAN
Devices are accessible to the external
interface/gateway (Internet). The Utility Public
Broadcast Channel is available but not used.
62
Deregulated Scenario
All devices sit on the third party network. The
electric distribution company provides
information through its Energy Services
Interface. The distribution companys
accountability boundary ends at the Retail
Gateway device. The Utility Public Broadcast
Channel is available but not used.
63
Section 3 The Requirements
  • In designing the system, the OpenHAN Core
    Development team considered a number of criteria.
    They are
  • HAN Applications
  • Communications
  • Security
  • Performance
  • Operations-Maintenance-Logistics

64
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

65
Criteria - HAN Applications
  • Any application that is enabled through the HAN
    will have one or more of the following
    characteristics
  • Control
  • Measurement and Monitor
  • Processing
  • Human-Machine Interface (HMI)

66
HAN Applications - Control
  • Control applications respond to control signals.
  • The simplest control application is direct
    control, which turns loads on or off.
  • Control applications can also cycle, which means
    they turn the load on and off at configurable
    time intervals.
  • More sophisticated control applications can limit
    the load of an appliance based on configurable
    thresholds.

67
HAN Applications Measurement and Monitor
  • Provide internal data and status.
  • Includes distributed generation functionality
    where local energy input and output is measured
    and monitored.
  • End-use metering functionality to measure and
    monitor device-specific energy consumption or
    production.
  • A consumer Plug-in Hybrid-Electric Vehicle
    (PHEV), for example, can have end-use metering
    functionality as well as distributed generation.
  • Applications can be as simple as measuring and
    monitoring the environmental state or whether a
    device is on or off.

68
HAN Applications - Processing
  • Consume, process and act on external and internal
    data.
  • These applications accept data from external
    systems and HAN measurement and monitoring
    applications.
  • Applications with processing capability are
    generally more complex and costly.
  • The following applications requiring processing
  • 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. based
    on the CO2 emission profile of a Utilitys
    generation portfolio)

69
HAN Applications - HMI
  • Most applications will need an HMI in order to
    provide local user input and/or output.
  • These applications are 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)

70
Criteria - HAN Communications
  • HAN Communications is one of the most challenging
    categories of the AMI systems.
  • The HAN SRS identified communications criteria
    for
  • Discovery
  • Commissioning
  • Control

71
HAN Communications - Discovery
  • Discovery of a node is simply the identification
    of a new node within the HAN and it generally
    involves the following
  • 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

72
HAN Communications - 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.
  • Commissioning involves the following
  • 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)

73
HAN Communications - Control
  • Control of a node is enabled by the platform
    specific technology and it involves
  • Organization - Communication paths (e.g., route)
  • Optimization - Path selection
  • Mitigation - Ability to adapt in response to
    interference or range constraints through
    detection and analysis of environmental conditions

74
Criteria - HAN Security
  • Introduction of a communications technology for
    the home requires enhanced security to protect
    the overall AMI system.
  • The UtilityAMI AMI Security Task Force addresses
    the security requirements of the AMI system in
    greater detail.
  • The HAN SRS addresses specific security criteria
    that pertain to the ESIs Utility-Secured
    Interactive Interface.
  • The security categories addressed are
  • Access Control and Confidentiality
  • Registration and Authentication
  • Integrity
  • Accountability

75
HAN Security Access Controls and Confidentiality
  • Levels of data protection based on data type.
  • All data will have some level of access control,
    but there are various requirements associated
    with 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, other premise metering data)

76
HAN Security Registration and Authentication
  • Crucial to verify and validate HAN participation.
  • Once a node is registered, it is trusted in the
    network.
  • Registration and authentication involves the
    following
  • Initialization Establishes the
    application/device as a validated node (i.e.,
    logical join to the Utilitys network)
  • Validation Validates the applications data
    (i.e., request or response)
  • Correlation Correlates an account (e.g.,
    Consumer) with a HAN Device, application, or
    program (e.g., demand response programs, peak
    time rebate, etc.)
  • Authorization Governs rights granted to the
    applications
  • Revocation Removes an established node,
    correlation, or authorization

77
HAN Security - Integrity
  • Preserves the HAN operating environment through
  • Resistance Methods which prevent changes to the
    application or applications data (e.g., tamper
    and compromise resistance)
  • Recovery Restores an application or the
    applications data to a previous or desired state
    (e.g., reloading an application, resending
    corrupted communications)

78
HAN Security - Accountability
  • Allows for monitoring malicious activities
    through
  • Audit Application log detected compromise
    attempts
  • Non-repudiation Applications and application
    operators are responsible for actions (e.g., can
    not deny receipt or response)

79
Criteria - HAN Performance
  • Ensures that applications or other factors do not
    limit the performance of the system.
  • Platform-independence dictates that these
    criteria are higher level than the others found
    in this document.
  • Less detailed than others for the same reason
    that, depending on Utilities technology
    selection, their performance requirements will
    differ.
  • Performance of the system is usually dependent on
    the following
  • 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

80
Criteria Operations, Maintenance and Logistics
  • Addresses the challenges around deploying HAN
    Devices in a new market segment.
  • The goal is to keep maintenance to a minimum and
    make the operation of the system as easy as
    possible while not compromising security and
    performance.
  • Activities involved in reaching this goal
  • Manufacturing and Distribution - Vendors
    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

81
(No Transcript)
82
Requirements Assumptions
  1. Consumer owns his Premise and Utilities are
    granted access rights by the consumer or by
    regulatory authority.
  2. The Utilities expect vendor differentiation and
    innovation in the marketplace.
  3. Devices do not prioritize commands (e.g., last
    command overrides previous).
  4. Assume orderly shutdown of operations (e.g.,
    could be delayed until current process
    completes).
  5. Does not presume source of message (i.e., Utility
    or certified premise EMS).
  6. Does not cover the consequences or incentives
    associated with participation or compliance
    (e.g., Overriding mandatory control signals).
  7. Certified premise EMS can proxy as the Utility.
  8. EMS devices are viewed as aggregating functions
    within the system.
  9. EMS can aggregate data from multiple sources.

83
Requirements Assumptions Cont
  1. Rate information can pass from the Energy
    Services Interface to the Energy Cost
    application.
  2. Energy Cost applications are not intended to
    reconcile costs displayed on HAN Devices with
    bills generated by a Utility billing system.
    There are other elements associated with billing
    and revenue-grade metering that are outside the
    scope of these requirements (e.g., revenue-grade
    certification, rate recovery).
  3. The Energy Cost applications are likely
    components of an Energy Management System.
  4. Alarm features would likely be part of separate
    Energy Optimization applications (e.g., signal an
    alarm when the accumulated cost for the month is
    greater than 100).
  5. For authentications to be considered secure they
    must not be able to be reversed with modern
    computing technology in the amount of time for
    which they are valid.

84
Requirements Assumptions Cont
  • All requirements comprise a shall statement
    that clearly outlines the requirement and
    minimizes the potential for confusion.
  • The requirements listed are not prioritized by
    criticality or sophistication and include some
    fairly advanced functional capabilities that may
    be beyond the current state of the market. This
    is intentional.
  • Readers should refer to Appendix 4.2 Logical
    Device Mappings for Utility-Registered Devices
    for guidance on which requirements are mandatory
    for logical devices to be considered UtilityAMI
    compliant.

85
Requirements Example - Control
  • 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.

86
Questions on Requirements?
  • Open document if necessary and look at individual
    requirements sections.

87
Appendices
  • Use Cases
  • Load and Energy Management
  • Energy Management System
  • User Information
  • Energy Storage and Generation
  • Fixed HAN Devices with Metering Capability
  • Mobile HAN Device with Metering Capability
  • System Configuration and Management
  • Logical Device Mappings

88
Logical 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

89
Device Mapping Example
Requ. ID OpenHAN System Requirements Energy Services Interface PCT Display EMS Load Control HAN Electric Meter HAN Meter (non-electric) Smart Appliance
App.Control.1 HAN Device shall accept control signals from the Utility. NA B B B B B B B
App.Control.2 HAN Device shall respond to requests to cease operational state (e.g., open contact). NA B NA B B NA NA E
App.Control.3 HAN Device shall respond to requests to resume operational state (e.g., close contact). NA B NA B B NA NA E
App.Control.4 HAN Device shall acknowledge receipt of control signal. NA B NA B B NA NA E
App.Control.5 HAN Device shall acknowledge execution of control request. NA B NA B E NA NA O
App.Control.6 HAN Device shall acknowledge execution failure of request (i.e., exceptions). NA E NA E E NA NA O
App.Control.7 HAN Device shall signal any consumer-initiated overrides. NA B NA B E NA NA O
App.Control.8 HAN Device shall respond to request to cease operation state at a specific time. NA B NA B E NA NA O
90
Question on Mapping?
  • Open document if necessary and look at individual
    sections.
About PowerShow.com