erich w. gunther utilityami chairman/facilitator chairman/cto – enernex corporation...
Post on 03-Jan-2016
214 Views
Preview:
TRANSCRIPT
Erich W. GuntherUtilityAMI Chairman/Facilitator
Chairman/CTO – EnerNex Corporationerich@enernex.com
Utility Industry AMI
Requirements Development
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
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)
Membership
UCAIug Organization
OpenDR => OpenSG
UtilityAMI WG OpenAMI WG
Requests for specific technologydevelopment and transfer of use cases
for ongoing support and evolution
OpenHAN TF AMI-Enterprise TF
OpenSGSubcommittee
UtiliSec WG
AMI-Sec TF
OpenSG Organization
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.
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.
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.
UtilityAMI Tasks
1. Glossary and Common Language Frameworka) A universal AMI glossary of terms and definitionsb) A framework for technology capability evaluationc) A common, minimum requirements definition document
2. Modular Meter Interface – Transferred to OpenAMIPolicy for modular communication interfaces in meters
3. Security – AMI-SEC Task Force (under UtiliSEC WG)Security issues and their relationship to business needs
4. Consumer Interface – OpenHAN Task ForcePolicy for Customer Portal interface to customer end user appliances
5. AMI Network Interface – AMI-Network Task Force Policy for AMI network to MDMD/head end & HAN interfacing
6. Back Office Interface – AMI-Enterprise Task ForcePolicy for MDMS to enterprise back office system connectivity
7. General Issues Forum – Information Exchange
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.
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.
1. American Electric Power (AEP)
2. Con Edison3. Duke Energy4. Electric Power Research
Institute (EPRI)5. Electricitie de France (EDF)6. First Energy7. Hawaiian Electric Company
(HECO)8. Keyspan Energy9. Sempra Energy (SDG&E)10.Southern California Edison
(SCE)
UtilityAMI Requirements DocumentRatification Vote Results
The Requirements
1) Standard Communication Board Interface
2) Standard Data Model3) Security4) Two-Way
Communications5) Remote Download6) Time-of-Use
Metering7) Bi-Directional and
Net Metering8) Long-Term Data
Storage9) Remote Disconnect
10) Network Management11) Self-healing Network12) Home Area Network
Gateway13) Multiple Clients14) Power Quality
Measurement15) Tamper and Theft
Detection16) Outage Detection17) Scalability18) Self locating
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 comm unications board.
The ability to mix and match communications protocols and meters and prevent being locked into a single vendors’ solution.
Physical and environmental specsElectrical specsProtocol specsCompatibility with existing form factorsAutomatic 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 protocolsUsable over multiple mediaClear requirements for enforcing interoperabilityGuidelines 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.
EncryptionAuthenticationCredential ManagementIntrusion DetectionLogging and auditing of all changes to data and configurationApplied in all parts of the networkApplied 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 protocolsBandwidth sufficient for remote downloadEasily extendedSecureDoes not interfere with other networksOn-demand reads with the ability to get consumption, load and voltage promptly (i.e. while on the phone with a customer).
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 controlMinimal impact on operationSecureAuditable
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 intervalsRemotely programmable number of rates and billing periodsTime 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 consumptionDemandInterval 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 meterLonger-term storage (60 days) in concentratorsConcentrators only store data - may validate, but do not estimate
UtilityAMI Requirements – Page 3
Requirement Description Benefits Expected Features
Remote Disconnect
The ability to disconnect or reconnect a customer’s 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 meterSwitch position on displayMeter 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-testsStatistics gatheringTrouble alarms sent spontaneously when necessaryRemote link enable/disableSignal strength monitoringPeriodic gathering of event logsAuditing of time synchronizationDetailed 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 pathsSwitchover algorithmsTraffic balancingData and configuration are not lost over power failuresGreater than 98% of meters successfully respond to each read
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 protocolCustomers can buy own equipmentSecureAbility 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 metersAggregation of meters into arbitrary groupsSecurity, 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/profileTotal Harmonic DistortionSags/Swells/InterruptionsHarmonicsPhase Voltage RMSClose 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 detectionRemoval detectionInactivity detectionBlink counts
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 outageStandardized open protocol interface to outage management systemsPer 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.
ModularityDistributed (non-hierarchical) processingAutomatic detection of new additionsConfigurable resource limitsOpen 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.
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
UtilityAMI 2008 HAN SRS
HAN SRS Ratification Vote Unanimous – Mar 7, 2008
AEP SCE SDG&E PG&E Detroit Edison FPL
BC Hydro Entergy Consumers Energy CenterPoint
Energy Oncor EDF
Endorsing Utilities:
Duke EnergyReliant Energy
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
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
Task Force and Liaison Reports
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
Marketing Collateral
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?
AMI-Network TF Proposal
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
Information Exchange
For which application areas not presently covered do you need common requirements for the purpose of influencing the AMI vendor community?
Other Application Requirements
Informative, Tech Transfer Venues GridWeek – Mon, Sep 22 – D.C. GridInterop – Wed, Nov 12 - Atlanta
Formal, Face-to-Face Meetings Oct 21-23 – Knoxville @ 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
Other Business, Next Meetings
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
Break
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
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
OpenHAN TF Deliverables
Use CasesRF reach scenarios
High rise scenarioUser scenarios
Customer moving from one utility to another?
Common RequirementsTo give vendors guidanceFor other organizations to develop detailsDerivative work from UtilityAMI requirements
Overarching Framework / Architecture
HAN SRS Ratification Vote Unanimous – Mar 7, 2008
AEP SCE SDG&E PG&E Detroit Edison FPL
BC Hydro Entergy Consumers Energy CenterPoint Energy Oncor EDF
Endorsing Utilities:
Duke EnergyReliant Energy
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
OpenHAN TF Agenda
Maintenance, Marketing and Support
Maintenance – Transfer to parent WGCurrent draft 1.04 fixes typos, grammar,
adds endorsersThe WG chair will handle further editorial
fixes as they ariseThe WG chair will consult the membership if
more significant issues need attention
Marketing – Transfer to UCAIugSupport – Usage, conformance
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
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
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
OpenHAN TF Agenda
Break
Break followed by in depth presentation of the UtilityAMI 2008 HAN SRS
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
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
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.
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.
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.
Table of Contents
Contents 1
1. Introduction .............................................................................................................7 2
1.1 Purpose........................................................................................................................................... 7 3
1.2 Scope.............................................................................................................................................. 8 4
1.3 Acronyms and Abbreviations .......................................................................................................... 9 5
1.4 Definitions ....................................................................................................................................... 9 6
1.5 External Considerations and References ..................................................................................... 14 7
1.6 Overview....................................................................................................................................... 15 8
2. Overall Description ...............................................................................................17 9
2.1 Guiding Principles......................................................................................................................... 17 10
2.2 Architectural Considerations......................................................................................................... 21 11
3. OpenHAN System Requirements .........................................................................28 12
3.1 Requirements Framework ............................................................................................................ 28 13
3.2 Requirements Assumptions.......................................................................................................... 33 14
3.3 Application Requirements............................................................................................................. 33 15
3.4 Communication Requirements ..................................................................................................... 38 16
3.5 Security Requirements ................................................................................................................. 40 17
3.6 Performance Requirements.......................................................................................................... 45 18
3.7 Operations, Maintenance, and Logistics Requirements............................................................... 46 19
4. Appendices...........................................................................................................49 20
4.1 UtilityAMI OpenHAN Task Force Use Cases ............................................................................... 49 21
4.2 UtilityAMI OpenHAN Task Force Logical Device Mappings for Utility-Registered Devices ......... 75 22
23
HAN Guiding Principles
Value Proposition
Guiding Principles
Use Cases
Platform Independent Requirements
Platform Requirements
(Technology Specific)
System Criteria
HAN Guiding Principles
1. Secure Two-way Communication Interface with the Meter
2. Supports Load Control Integration3. Direct Access to Usage Data4. Provides a Growth Platform for Future Products
Which Leverage HAN and Meter Data5. Supports Three Types of Communications: Public
Price Signaling, Consumer-Specific Signaling, and Control Signaling
6. Supports Distributed Generation and End-Use Metering
7. Consumer Owns the HAN8. Meter-to-HAN Interface Is Based on Open Standards
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.
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.
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.
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.
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.
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.
7. Consumer Owns the HAN
DescriptionHAN 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.
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.”
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.
Questions on Guiding Principles?
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
Interface
AMI Backhaul Network
Utility Publ
ic Broa
dcast C
hannel
(Events,
& price
signal
)
(Energy Services
Interface)
Utility Secu
red Int
eractiv
e
Interfa
ce
Early Implementation Scenario
AMI Backhaul Network
PCTRegiste
red Cons
umer
Device
(Secured
)
Utility Publ
ic Broa
dcast C
hannel
(Events,
& price
signal
)
Meter
(Utility Services Interface)
Utility interacts with a registered (Voluntary) PCT. The Public Broadcast Channel interface is used to provide price signals and grid event messages to the Consumer’s unregistered Smart Appliance. The ESI is located in the meter under glass.
Customer Choice Scenario
AMI Backhaul Network
Load Control
Registe
red Cons
umer
Device
(Secured
)
Utility Devi
ce
(Secured
)
Distributed Generation
Smart AppliancePlug-in Hybrid
Consum
er Devi
ce
Utility Publ
ic Broa
dcast C
hannel
(Events,
& price
signal
)
Premise Meter
(e.g., Gas)
PCT
Premise EMS
Meter
(Utility Services Interface)
External Interface
(Internet)
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.
Mature System Scenario
AMI Backhaul Network
Load ControlPCT
Plug-In Hybrid Advanced In
Home DisplayRegi
stered
Consum
er Devi
ce (Secu
red)
Utility Devi
ce
(Secured
)
Lighting Control
Smart ApplianceHealth Care
Set Top Box
Consum
er Devi
ce
Distributed
Generation
Utility Publ
ic Broa
dcast C
hannel
(Events a
nd pric
e sign
al)
Premise Meter
(e.g., Gas)
Premise
Electric Meter In Home Display
Premise EMS
Energy Services Interface
External Interface
(Internet)
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.
Deregulated Scenario
AMI Backhaul Network
Distributed Generation
Smart AppliancePlug-in Hybrid
Retail E
nergy
Provide
r Netw
ork
Utility Publ
ic Broa
dcast C
hannel
(Events a
nd pric
e sign
al)
PCT
Distribution to
Retail Gateway
Energy Services Interface
External Interface
(Internet)
All devices sit on the third party network. The electric distribution company provides information through its Energy Services Interface. The distribution company’s accountability boundary ends at the Retail Gateway device. The Utility Public Broadcast Channel is available but not used.
Section 3 – The Requirements
In designing the system, the OpenHAN Core Development team considered a number of criteria. They are:HAN ApplicationsCommunicationsSecurityPerformanceOperations-Maintenance-Logistics
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
Criteria - HAN Applications
Any application that is enabled through the HAN will have one or more of the following characteristics:ControlMeasurement and MonitorProcessingHuman-Machine Interface (HMI)
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.
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.
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 Utility’s generation portfolio)
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)
Criteria - HAN Communications
HAN Communications is one of the most challenging categories of the AMI systems.
The HAN SRS identified communications criteria for:DiscoveryCommissioningControl
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
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 deviceAuthentication - Validation of the device (e.g., the
network key)Configuration - Establishing device parameters
(e.g., network ID, initial path, bindings)
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 selectionMitigation - Ability to adapt in response to
interference or range constraints through detection and analysis of environmental conditions
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 ESI’s Utility-Secured Interactive Interface.
The security categories addressed are:Access Control and ConfidentialityRegistration and Authentication IntegrityAccountability
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)
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 Utility’s network)
Validation – Validates the application’s 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
HAN Security - Integrity
Preserves the HAN operating environment through: 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)
HAN Security - Accountability
Allows for monitoring malicious activities through: Audit – Application log detected
compromise attemptsNon-repudiation – Applications and
application operators are responsible for actions (e.g., can not deny receipt or response)
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
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 - 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
Applications
DirectControl
Cycling Control
Limiting Control
Distributed Generation
Submetering
EnvironmentState
Device State
EnergyCost
Energy Production
Energy Optimiza-
tion
Energy Demand
Reduction
EnvironmentImpact
UserInput
UserOutput
ControlHuman
MachineInterface
MeasureMonitor
System*
Communications
Control
Announce
Respond
Identify
Authenticate
Organize
Optimize
Prioritize
Mitigation
Security PerformanceOperations
MaintenanceLogistics
Availability Reliability Maintain-
ability
Scalability Upgrade-
ability Quality
Lev
el 4
Lev
el 2
Lev
el 3
Lev
el 1
Integrity Account-
abilityRegistration
Authentication
AccessControl
Confidenti-ality
Public
Private
Utility
Initializa-tion
Validation
Correlation
Resistance
Recovery
Audit
Non-Repudaition
Revocation
Pre-commision
Registrationconfig
Labeling
Document
Support
AlarmLogging
Testing
Reset
Installation ManufactureDistribute
Manage Maintain
Purchasing
Platform Independent Requirements
CommisionProcessing
Energy Consumption
Authorization
Payment
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.
Requirements Assumptions – Con’t
10. Rate information can pass from the Energy Services Interface to the Energy Cost application.
11. 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).
12. The Energy Cost applications are likely components of an Energy Management System.
13. 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).
14. 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.
Requirements Assumptions – Con’t
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.
Requirements Example - Control
Context:Applications that respond to control commands from the utility orauthorized third parties. Commands typically tell a device to turn ON/OFF atconfigurable 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.
Questions on Requirements?
Open document if necessary and look at individual requirements sections.
Appendices
Use CasesLoad and Energy ManagementEnergy Management SystemUser InformationEnergy Storage and GenerationFixed HAN Devices with Metering CapabilityMobile HAN Device with Metering CapabilitySystem Configuration and Management
Logical Device Mappings
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
Device Mapping Example
Requ. IDOpenHAN System
Requirements
Energy Services Interface
PCT Display EMSLoad
Control
HAN Electric Meter
HAN Meter (non-
electric)
Smart Applianc
e
App.Control.1HAN 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.4HAN Device shall acknowledge receipt of control signal. NA B NA B B NA NA E
App.Control.5HAN 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.7HAN 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
Question on Mapping?
Open document if necessary and look at individual sections.
top related