Erich W. Gunther, P.E.Chairman and CTO
EnerNex Corporation
ChairmanUtilityAMI, OpenHAN,
CA Title 24 PCT Reference Design Task Force
Home Area Network
Workshop
• Introductions• Context Setting
• EPRI Consumer Portal Project Overview• California Influence
• Reference Design for AMI and DRI• Demand Response –Title 24 PCT
• Industry Response• OpenAMI Overview• UtilityAMI Overview
• Questions and Discussion• Break• OpenHAN – What have we been up to?• Security – Examples, Issues, Opportunities• Questions and Discussion• Adjourn - Lunch
Agenda
Questions before proceeding?
EPRI Consumer Portal Overview
Consumer Portal FAQ Copyright © EPRI 2005 – 4
Consumer Portal FAQ
• What is a Consumer Portal?
• Why are we talking about portals?
• How would a portal be used?
• What could portals do?
• Which functions of a portal are most important?
• How could portals make money?
• What could a portal look like?
• What do YOU think?
Consumer Portal FAQ Copyright © EPRI 2005 – 5
What is a Consumer Portal?
“A combination of hardware and software that enables two-way communication between energy service organizations and equipment within the consumers’ premises.”
Consumer Portal FAQ Copyright © EPRI 2005 – 6
What is a Consumer Portal?
More Possible Definitions
• A “router” that just forwards messages
• A “gateway” that translates technologies
• A “single point of access”:– From multiple organizations
– To a variety of customer premises equipment
• A “virtual device” that may be located in:– A meter
– A thermostat
– A PC
– A set-top box
– All or none of the above
• A “window” into the customer site
Consumer Portal FAQ Copyright © EPRI 2005 – 7
Why are we talking about portals?
• Frustration– Too many failed attempts
– Proprietary systems
– Unable to deploy on large enough scale
• Regulation– California, Ontario, New York, etc.
– Trying to “level the playing field”• Reduce barriers for vendors
• Make costs common to all
• Ensure common service for consumers
• Evolution– Recent events putting pressure on the grid
– Must find a way to adapt
Consumer Portal FAQ Copyright © EPRI 2005 – 8
Why are we talking about portals? The Power System is Under Pressure!
• Reliability– 2003 Northeast Blackout
– The grid is “brittle”
• Security– Terrorist attacks
– The grid is vulnerable
• Markets– Deregulation, opening of energy markets
– Unprecedented sharing of data
• Consumer Demands– Distributed generation, green energy, need for hi-quality power
– Consumers are demanding a say in the operation of the grid
Consumer Portal FAQ Copyright © EPRI 2005 – 9
Why are we talking about portals? Portals Lead to an Intelligent Power Grid
• The IntelliGrid Consortium:– A group of Utilities, vendors, researchers and governments
– Goal is a grid communications system for a “digital society”
– Has developed an architecture: www.epri-intelligrid.com
– Intended to address the pressures discussed here
– A grid that automatically predicts failures, heals, optimizes, and interacts with customers
• Where does a consumer portal fit in?– High volumes of timely, accurate information
– Gathered from millions of customer sites
– Enables more responsive simulation, modeling, optimization, prediction, and markets
Consumer Portal FAQ Copyright © EPRI 2005 – 10
How could a portal be used? A scenario.
• A “heat storm” is due tomorrow
• Energy service provider notifies consumers that a “super peak” tariff is coming
• Consumer previously told the portal how to react
• Some consumers permitted to bid into the load reduction market
Allow Load Control
Setback Cooling by 2°
Your current usage is 35.85 kW
Load control is currently in effect with a 4°F cooling setback scheduled to take effect at 3:00 PM
Your energy consumption for this billing period is 6240 kWh costing an estimated $998.40
By managing your energy you have saved an estimated $108.47 in this billing period
Set Price Response Options
A message from California Power Company: The system is operating well and no emergency load reduction requests are expected today. Tomorrows forecast is for hotter and more humid so prices will be up be up again tomorrow. We appreciate your business.
Tomorrow's forecast is hot, hazy and humid with a high of 110°
Cycle Water Heater
Reduce Lighting
Setback Cooling by 4°
California Power Company
Consumer Portal FAQ Copyright © EPRI 2005 – 11
How could a portal be used? The Response
• Portal adjusts load when the new rate hits:– Increases thermostat setting
– Turns off water heater
• User could have provided input:– Viewed the tariff change
– Adjusted settings
– Viewed $$ savings
• But not necessary!
• Portal reacts anyway.
Consumer Portal FAQ Copyright © EPRI 2005 – 12
How could a portal be used? An Emergency
• Tree contact causes transmission line fault
• Transmission lines overloaded
• ISO issues load reduction request to portals
• Each portal cuts back load drastically
• Distribution operator queries all portals in the area
• Extent of the outage becomes clearly visible
• Operator acts quickly to partially restore power
Consumer Portal FAQ Copyright © EPRI 2005 – 13
What could portals do?
A portal could have many clients:
• Residential and commercial consumers
• Energy service providers
• Independent system operators
• Distribution companies
• Other utilities
• Non-utility organizations
• Others
Each of these clients could use it differently.
Consumer Portal FAQ Copyright © EPRI 2005 – 14
What could portals do?
Advanced Metering and Demand Response
Consumer Site
Portal
Utility
Aggregated metering data
· New tariffs· Emergency
Indications
Energy measurements
Load controls
Consumer Portal FAQ Copyright © EPRI 2005 – 15
What could portals do?
Residential Customer Services
Portal
· Billing info· Energy usage· Energy savings· Emergency indications
· Contract terms· Trouble indications· Choice of ESP
· Trouble Reports· Choice of ESP· Response settings
Utilities
`
Consumer
Consumer Portal FAQ Copyright © EPRI 2005 – 16
What could portals do?
Advanced Customer Services
• Integrate with local Energy Management System
• Optimize energy use
• Compute energy efficiency
• Control distributed generation
• Coordinate load profiles between buildings
• Submit bids to energy markets
Portal
· Load bids· Generation bids· Power quality
reports
Response Market
Generation Market
Utility
Energy measurements
Pricing info
EMS
Consumer Portal FAQ Copyright © EPRI 2005 – 17
What could portals do?
Customer Management
• Remotely connect or disconnect customers
• Detect tampering
• Detect theft of energy
• Limit maximum load in response to billing irregularity
`
AccountManager
Portal
· Connect· Disconnect· Set Limits
Alerts
· Tamper indications· Energy measurements
Consumer Site
Consumer Portal FAQ Copyright © EPRI 2005 – 18
What could portals do?
Widespread Distribution of Data
• Provide large volumes of accurate data for marketing, simulation, modeling, and predictive maintenance
• Aggregate data from multiple types of utilities
• Stagger load pickup in “black start” emergencies
Database
DetailedEnergy
Measurements
Markets
Research
Utility Operations Portals at Consumer Sites
Consumer Portal FAQ Copyright © EPRI 2005 – 19
What could portals do?
Advanced Distribution Operations
• Detect and isolate outages more quickly
• Shed load with finer control
• Use demand response customers as a “fast reserve”
• Monitor and optimize power quality more accurately
• Monitor and control distributed generation
• Minimize system losses
Portal
· Switch generation· Shed load· Transfer load
DistributionOperator
· PQ data· Volt/VAR data· Trouble reports
Measurements
· Load controls· Generation
controls
EMS
Consumer Portal FAQ Copyright © EPRI 2005 – 20
Portal
Consumer Site
· Security alerts· Medical monitoring· Environmental info· Others
· Entertainment· Efficiency data· Others
AdvancedServices
What could portals do?
Non-Energy Applications
Also:
• Weather forecasting
• Flooding and freezing alerts
• Air quality
• Optimize building heating and lighting
Consumer Portal FAQ Copyright © EPRI 2005 – 21
Which portal functions are most important?
• Feedback from IntelliGrid Consortium members
0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50
Energy Efficiency Services
Outage, Tamper and Theft Detection
Automatic Meter Reading
Customer Connect/Disconnect/Set Limit
Demand Response and Load Shifting
Power Quality Monitoring
Customer Change of Energy Supplier
Metering Data for Market Settlement
Advanced Pricing and Real Time Pricing
Integration of Distributed Generation
Integration with Customer EMS
Aggregation of Multi-Energy data
Non-Energy Services
Average Rated Importance (1-5)
Consumer Portal FAQ Copyright © EPRI 2005 – 22
How Could Portals Make Money?
Benefits:
• Increased system efficiency, stability, and power quality
• Cumulative savings from demand response
• Avoided costs of incremental capital investment
• Recovered costs:– Theft detection– Fewer outages
• New income:– New value-added services– Participation in markets with better
data
Barriers:
• Cost of equipment– Portal itself (unless embedded in
other devices)– Peripherals, e.g. meters, thermostats,
EMSs
• Cost of deploying networks– To the consumer site– Within the consumer site
• Cost of operation– Signing up customers – Technical support– Billing infrastructure
Consumer Portal FAQ Copyright © EPRI 2005 – 23
How could portals make money?
EPRI Study - 2004
• 5-20 year assessment of California market
• 15% discount rate assumed
• $15B benefit to society AFTER investors have earned 15%!
-$3,000 -$2,000 -$1,000 $0 $1,000 $2,000 $3,000 $4,000 $5,000 $6,000 $7,000
Consumer Portal Investment
Operating and Maintenance Costs
Energy Cost Savings due to DemandResponse
Avoided Costs
System Benefits
Reliability and PQ Benefits
Energy Efficiency and Energy Services
Net Present Value of Cost/Benefit (x$1000)
NPV of Costs/Benefits = $14.7B
Consumer Portal FAQ Copyright © EPRI 2005 – 24
How could portals make money?
Lessons Learned – from dozens of past attempts
• The technology exists.– No breakthroughs are necessary
• Make it simple.– Customer must be able to not participate
• Standardize.– Don’t try to “lock in” customers to proprietary systems– Achieve economies of scale and reduce costs
• Share the infrastructure.– Use portal-like services from other industries
• Build an architecture.– Integrate the portal with the whole energy system– Don’t create “islands of automation”
• Don’t strand assets.– Make it easy and inexpensive to upgrade– The best applications may be yet to come
• Share the benefits.– Distribute the “societal benefits” to everyone
Consumer Portal FAQ Copyright © EPRI 2005 – 25
What could a portal look like?
• A consumer portal is an idea, not a particular device!
• IntelliGrid is developing a reference design– A standard “virtual appearance” for a portal
– A clearly defined set of interfaces
– May be incorporated into a variety of devices
– May be distributed among several devices
• The physical device(s) may vary, but the virtual device must be standardized to ensure
– Interoperability between vendors
– Reduction in cost due to economies of scale
• Some vendors already provide portal-like devices, but they are not standard and not interoperable.
Consumer Portal FAQ Copyright © EPRI 2005 – 26
What could a portal look like? Some Options:
`
ADSL
PLC
CableNetwork
SONET WAN
EMS
`
Portal in a meter
Portal in a local energy management systemPortal in a stand-alone device or PC
Portal in a set-top box
Consumer Portal FAQ Copyright © EPRI 2005 – 27
What could a portal look like?
Possible User Interfaces
• A web page– Through Internet or directly
• A television interface– Similar to web interface
– Through a set-top box
• A simple control panel– Colors to indicate tariffs
– Buttons to control responses
• A single light – To indicate emergency curtailment
– To indicate level of rates applied
• ...or others
Consumer Portal FAQ Copyright © EPRI 2005 – 28
What could a portal look like?
Characteristics
Every portal would have the SAME:
• Minimum data model
• Security scheme
• Upgrade mechanism– Tariffs
– Configuration
– Applications
The following things could be DIFFERENT:
• Innovative additions to the minimum data model
• In-building communications technology
• Wide-area network technology
• User Interface
Consumer Portal FAQ Copyright © EPRI 2005 – 29
What do YOU think?
• These have been some of the common ideas about portals
• Many people have different viewpoints
• Discussion: What do YOU think?
AMI / DR Reference Design CEC PIER Title 24 Reference
Design
Questions before proceeding
California Influence
CALIFORNIA ENERGY COMMISSION
Background The electricity crisis of 2000/2001 had many
contributing factors Market power (Enron, et al) Aging fossil fuel plants (pollution) Flaws in deregulation (AB 1890) Disconnect between wholesale and retail prices
However, most agree that one mitigating factor was missing
DEMAND RESPONSE
CALIFORNIA ENERGY COMMISSION
CEC Policy & Programs
Under the leadership of Commissioner Rosenfeld, the CEC along with the CPUC, CPA, and the State’s 3 major IOU’s embarked upon a path to encourage DR through “price-responsive” load
In support of this CEC policy and program, PIER initiated a DR Program to perform related R&D
Consultant Report: “A Strawman Reference Design for Demand Response Information Exchange” - http://ciee.ucop.edu/dretd/
CALIFORNIA ENERGY COMMISSION
Reference Design Project Genesis
Implementing DR policy requires implementing a demand responsive infrastructure
Stakeholders had widely varying views as to how such an infrastructure could be deployed
Most if not all of those views were incompatible with each other, were not based on standards, were not scaleable, and would have likely resulted in more stranded assets in the long run
The concept of a reference design as used in other industries came to mind as a way of mitigating this problem
CALIFORNIA ENERGY COMMISSION
LSE
ISO
UDC
Translation
Domain of “Open Systems”based information exchange
between “Applications”Open Systems Elements
Protocol (e.g. TCP/IP)Language (e.g. XML)Objects (e.g. independent of above)Security (e.g. HTTPS, SSL / TLS)
INT
ER
OP
ER
AB
ILIT
Y
ApplicationsMeteringDER/DA OperationsMaintenance
Information FlowReference Model
ApplicationsLoad aggregationBillingOn-line Services
ApplicationsGrid ManagementPrice CalculationDispatchMarket OperationsEmergency Control
Existing SystemsProprietary InterfacesSensor Networks-----------------------------Any protocolAny language
LegendISO – Independent System OperatorLSE – Load Serving EntityUDC – Utility Distribution Company
Back of the Napkin Concept
CALIFORNIA ENERGY COMMISSION
Characteristics of Infrastructure
Shareability - Common resources offer economies of scale, minimize duplicative efforts, and if appropriately organized encourage the introduction of competing innovative solutions.
Ubiquity - All potential users can readily take advantage of the infrastructure and what it provides.
Integrity - The infrastructure operates at such a high level of manageability and reliability that it is often noticeable only when it ceases to function effectively.
Ease of use - There are logical and consistent (preferably intuitive) rules and procedures for the infrastructure's use.
CALIFORNIA ENERGY COMMISSION
Characteristics of Infrastructure
Cost effectiveness - The value provided must be consistent with cost or the infrastructure simply will not be built or sustained.
Standards - The basic elements of the infrastructure and the ways in which they interrelate are clearly defined and stable over time.
Openness - The public infrastructure is available to all people on a nondiscriminatory basis.
Secure - The infrastructure must be protected against unauthorized access, interference from normal operation, and facilitate implementing information privacy policy
CALIFORNIA ENERGY COMMISSION
Demand Response Infrastructure: Principles and Goals
The DRI must provide a set of interfaces, transactions and services to support current and envisioned demand response functions.
The DRI must serve all constituents. The DRI must promote the principles of free
enterprise. The DRI must protect the rights of users and
stakeholders. The DRI must promote interoperability and open
standards.
CALIFORNIA ENERGY COMMISSION
Purpose of the DR Reference Design
To establish a common starting point for implementing open information exchange for a DR infrastructure whose characteristics include:
Scalability Interoperability Facilitating Innovation (cheaper, better, faster) Maintaining Compatibility (existing and proprietary systems)
Guarantees regulatory bodies the ability to develop tariffs, programs and other currently unknown initiatives
To protect the integrity of California’s power delivery system
CALIFORNIA ENERGY COMMISSION
Example:Emergency Load Curtailment
Present Day The ISO has no idea of how much ELC is available, how will or did the system
respond, nor is it enough to stabilize the system ISO issues command in different ways to different IOU’s Each IOU sends ELC signal to their subscribed loads using different methods
with varying latencies and feedback Future
Available ELC providers known to ISO through a common information system including stats on available ELC and expected response magnitude and delay
ISO broadcasts ELC signal using a single, standard method to all IOU’s, ESP’s, LSE’s, and other providers
Each provider relays ELC signal using standard interface to all subscribers Subscriber response is confirmed, logged, and reliability statistics are updated
and made available immediately to the ISO Regulators are able to audit program effectiveness, system capacity and actual
performance
CALIFORNIA ENERGY COMMISSION
Strawman Reference Design
Zones of information exchange Inside is a domain of open systems information
exchange Outside is a domain of existing and proprietary devices
and systems Between the two exists a defined set of
interfaces The reference design is the set of implementing
standards and technologies
CALIFORNIA ENERGY COMMISSION
Reference Design Components Actors - the entities that need to exchange information
(e.g., CAISO, LSE’s, and UDC’s) Applications - the functions that need to be performed by
the actors Protocol - the underlying communication methods used to
move bits and bytes Language - a common language to facilitate information
exchange Objects - high-level definitions of objects that are
independent of protocol and language Translation - services that provide a way to allow
information exchange with external systems Security - overarching methods to ensure confidentiality,
integrity, and availability
CALIFORNIA ENERGY COMMISSION
Domain of “Open Systems”based information exchange
between “Applications”
Open Systems ElementsProtocol (e.g. TCP/IP)Language (e.g. XML)Objects (e.g. CIM, ANSI, 61850)Transactions (e.g. GID, ebXML)Security (e.g. HTTPS, SSL / TLS)
INT
ER
OP
ER
AB
ILIT
Y
UDC ApplicationsMeteringDER/DA OperationsMaintenance
LSE ApplicationsLoad aggregationBillingOn-line Services
CAISO ApplicationsGrid ManagementPrice CalculationDispatchMarket OperationsEmergency Control
Customer ApplicationsBuilding ManagementAppliance OptimizationThermal ControlLoad Control
LegendISO – Independent System OperatorLSE – Load Serving EntityUDC – Utility Distribution Company
Translation ServicesExisting SystemsProprietary InterfacesSensor NetworksAny protocolAny language
Regulatory ApplicationsOversightRate validationCompliance
Demand Response Reference Design
Database ApplicationsData CollectionData StorageData ProcessingBilling FilesData PublishingData Archives
CALIFORNIA ENERGY COMMISSION
Interfaces and Transactions DR information exchange infrastructure is typically specified
in terms of interfaces and transactions. Interfaces constitute points of connection or interaction among system
components. They often refer to places where entities may offer services or link systems; they also may refer to the links at boundaries of layers of various functions.
Transactions specify sets of rules and formats that determine the communication behavior between entities
Any new system capability will have to connect via an existing or standard interface, even if some of the properties are tailored to the specific nature of the service.
It is essential that the system's key interfaces and transaction models be open to future evolution and development.
It is important to specify both the underlying services and the information objects exchanged across the infrastructure.
CALIFORNIA ENERGY COMMISSION
Review – The Premise
Demand Response (DR) will become a major resource to deal with California’s future electricity problems
An advanced metering infrastructure will be deployed on a large scale throughout the state
Price signals will be used to induce load response when contingencies and market imbalances exist
Technology will act as a proxy for end users (e.g. respond to signals and take action)
CALIFORNIA ENERGY COMMISSION
Implications
If the premise is true, then Information exchange will be required between
several organizations and systems Numerous applications that create and consume
information will exist
CALIFORNIA ENERGY COMMISSION
For there to be seamless exchange of information in ways that we can’t fully define today, there has to be a common reference design for California’s demand response infrastructure
Conclusion
CALIFORNIA ENERGY COMMISSION
Questions ???
California PCT CEC Title 24 Building Standards
Current code mandates PT’s 2008 revision mandates PCT’s
Specifies minimum requirements Points of Interoperability
Communications Interface HVAC Interface Human Interface Expansion Interface
California WAN -1 Way RDS Paging
Reasons for PCT Interface Specs One PCT for all of CA (US)
Retail purchased at Home Depot, etc.Consumer owned, installed, maintained
Common signaling throughout CA (US) Works with any minimum AMI system
Signals synched with AMI resolution Compatible with legacy technologies
Preserve richness of thermostat options
Title 24 Code Language (i) Thermostats – All heating and/or cooling systems shall
have a Programmable Communicating Thermostat (PCT) that meets the requirements of Subsections 150(i)(1) and 150(i)(2) below: (1) Setback Capabilities - All PCTs shall have a clock mechanism
that allows the building occupant to program the temperature set points for at least four periods within 24 hours. Setback thermostats for heat pumps shall meet the requirements of Section 112(b).
(2) Communicating Capabilities – All PCTs shall be distributed with a non-removable communications device that is compatible with the default statewide DR communications system (to be determined), which can be used by utilities to send price and emergency signals. PCTs shall be capable of receiving and responding to the signals indicating price and emergency events as follows.
Title 24 Code Language Price Events – The PCT shall be shipped with default price-
event offsets of +4°F for cooling and -4°F for heating; however, customers shall be able to change the offsets and thermostat settings at any time, except during emergency events. Upon receiving a price-event signal, the PCT shall adjust the thermostat setpoint by the number of degrees indicated in the offset for the duration specified in the signal of the price event.
Emergency Events – Upon receiving an emergency signal, the PCT shall respond to commands contained in the emergency signal, including changing the setpoint by any number of degrees or to a specific temperature setpoint. The PCT shall not allow customer changes to thermostat settings during emergency events.
And, the PCT Must: A. Include at least one industry standard
expansion/communication port. Insertion of a utility-specific communications module shall disable the default statewide communications hardware built in to the PCT unless the utility module is removed or is no longer receiving a signal.
B. Provide user information regarding communications system connection status, type of event (price or emergency), and other maintenance-related information. This information shall be on the standard PCT display, using a Liquid Crystal Display, standalone indicator using Light Emitting Diodes, or other means.
C. Be equipped with a standard connector on a wall plate capable of interfacing with the HVAC equipment. The connector shall have the capacity to support at least 6 analog thermostat wires, at least 3 digital communications wires, and 24 volt power supply.
PCT Architecturepower
memory
clock
CPU
other
volatilenon-volatile
communications
output
input
input
parallel
serial
output
input
internal
4-, 8-, 16-,32-bit μp{
{
output
I/O
analog
digital
expansionports
humaninterface
D/A
A/D
isolation
Basic (Mandatory) HVDC InterfaceTerm # Signal Name Normal
Color Notes
1 C: 24 Vac Common Black 24Vac transformer neutral 2 R: 24 Vac Power Red 24Vac transformer power. In a two source
transformer installation, this terminal becomes Rh.
(Conventional) Y: Cooling 3
(Heat Pump) Y: Compressor
Yellow Conventional - First stage cooling
Heat Pump - First stage compressor. Will heat and cool based on the output of terminal 5 - O/B
(Conventional) W: Heating 4
(Heat Pump) O/B: Compressor
White Conventional - First stage heating
Heat Pump – Configurable option to energize the terminal for cooling (O option) or heating (B option)
5 G: Fan Green Fan switch on thermostat or on a call for cooling or heat pump
6 (opt) Rc: 24 Vac Power Red OPTIONAL. Cooling transformer power for two source transformer installations. This terminal can be tied to terminal #2 in single transformer installations.
Advanced (Optional) InterfaceTerm # Signal Name Normal
Color Notes
(Conventional) W2: Second Stage Heating
7
(Heat Pump) Aux/E: Auxiliary Heating
Various Conventional - Second stage heating
Heat Pump – Auxiliary and emergency heating control relay.
8 Y2: Second Stage Cooling Blue or Orange
Second stage cooling for both Conventional and Heat Pump configurations
9 L: Equipment Fault Various Installed as an input based on equipment type. When configured as in input, activation of the external generated signal informs the user via icon or LED enunciation, that the heat pump system is not available.
Installed as an output based on equipment type. This output is used to “inform” zoning equipment that the system is in emergency heat mode. In this situation the secondary piece of equipment (zoning panel) will disable a call for heat pump.
(Conventional) W3: Third Stage Heating
10
(Heat Pump) Aux2: Second Stage Auxiliary Heating
Various Conventional - Third stage heating
Heat Pump – Second stage auxiliary heating
Communications Interface - WAN
Expansion Interface - MMC MMC System Specification Version 3.31 Serial Peripheral Interface (SPI) Optional: MMC version 4.1 or SDIO version 1.1
Communications: Messaging Model
Description of Messages & Data Payloads Required for the CEC Title 24 PCT Specification
Messages Recognize Two Basic System Event ModesPrice EventsEmergency Events
Messaging Model
Data Classes for Most MessagesAddressingEvent IdentificationTime StampingCrypto
Event ID ImportanceFacilitate cancellation of eventsPermit multiple event transmissions for
message transport reliability
Addressing Scheme Enables Regional or PCT Level FilteringPlace holder for value added information to
facilitate PCT side filtering Two Levels of PCT Operational Status
Visual Indication PossibleUnderlying Physical Communication Layer
e.g. – carrier heartbeatDerived from the last valid message received
Clock Sync Message PCT displays error message if a valid time sync
not received in 24 hr period
Price Events
Utility desire to communicate a “super peak rate” period is in effect either by:Simple message that price is in effectExplicit price
Price event message definitionStart and stop time & the price If the price field = zero then a generic super-
peak event with no specific price
Consumers PCT has default response to price event, but customer may override programming
PCT Vendors have design flexibility for owner response and / or event & price information
Reliability Events
Provides Utilities specific directives to PCT to address reliability Start and Stop TimeAdvance SchedulingReliability Selections
Change Temperature Set Temperature
Emergency Event – Special Reliability ClassCoded separately to facilitate expedited
handlingFor example
Normally, PCT events could be cached in area concentrator; then forward when network traffic permits
Area concentrator inspects message header and if emergency detected forwards message immediately with potential auto retransmissions
Messaging Specification – Data ClassesAddressing <ADDR> Common Addressing Information <ADDR>
Attribute Name Attr. Type Explanation M/ O
Data
Source Utility INT8U Utility / DisCo which controls the PCT (Ex: 5=SCE) M
DR Program INT8U Demand response program identifier (Ex: 3=CPP,1=non-curtailable) M
Area / Sub Ident INT16U Locates customer (Ex:0=ALL, 1..999 is area, 1000 up are substation idents M
Feeder Identifier INT8U Feeder number within a substation (0 = all feeders, 1..N = feeder) M
Billing Point Ident INT64U Identifies individual customer (ex: 5 = LADWP) O
Date/Time Stamp <DTIME> Common Date/ Time Information <DTIME>
Attribute Name Attr. Type Explanation M/ O
Data
NTP_Seconds INT32U Seconds since 0h J anuary 1, 1900 UTC M
NTP_Fraction INT32U Fractional seconds M
Event Identification <EV_ID> Common Event Identifier <EV_ID>
Attribute Name Attr. Type Explanation M/ O
Data
Event_ID INT16U Message serial number used for event identification, acknowledgement, and cancellation
M
Messaging Specification – Data Classes
Event Price <PRICE> Common Event Identifier <EV_ID>
Attribute Name Attr. Type Explanation M/ O
Data
Event_Price INT16U $ / KWH * 0.0001 (Ex:2000 = $0.20 / KWH) M123
Event_Price_Ratio INT16U Event price is normal price x this_value / 100 (i.e. 200 means 2x price) M123
Event_Price_Tier INT8U Indicator of relative price (ex:1=normal, 2=high, 3=very high, >1000 is a Tier ID)
M123
Note: One of the three M123 elements is mandatory
Messaging SpecificationReliability Event – Change Temperature Reliability Event (change temperature) Command
Attribute Name Attr. Type Explanation M/ O
Data
Command Code INT8U (ex: 3) M
Address <ADDR> Which PCTs should use this information (this may be ignored) M
Start_Time <DTIME> Event begin time M
Stop_Time <DTIME> Event end time M
Event_ID <EV_ID> Identifier of this price event (used for cancellation) M
Temp_Change INT8U Amount to change setpoint in 0.1 degree Celsius M
Crypto <CRYPTO> Message integrity value O
Note: Setpoint change sign is not specified – the thermostat knows which direction to change based on current mode for energy savings
Price Event Price Event Notification
Attribute Name Attr. Type Explanation M/ O
Data
Command Code INT8U (ex: 2) M
Address <ADDR> Which PCTs should use this information (this may be ignored) M
Start_Time <DTIME> Event begin time M
Stop_Time <DTIME> Event end time M
Event_ID <EV_ID> Identifier of this price event (used for cancellation) M
Event_Price <PRICE> One of three possible price options – see <PRICE> M
Crypto <CRYPTO> Message integrity value O
Human Interface Requirements The PCT shall be shipped with default price-event offsets
of +4°F for cooling and -4°F for heating; however, customers shall be able to change the offsets and thermostat settings at any time, except during emergency events.
The PCT shall not allow customer changes to thermostat settings during emergency events.
Provide user information regarding communications system connection status, type of event (price or emergency), and other maintenance-related information. This information shall be on the standard PCT display, using a Liquid Crystal Display, standalone indicator using Light Emitting Diodes, or other means.
Through user input be capable of addressability at the substation level or finer including individual.
1. Introduction............................................................................................................................. 3 2. HVAC System Interface ......................................................................................................... 3
2.1 Minimal Direct Control Interface ........................................................................................ 3 2.2 Advanced Thermostat Direct Control Interface................................................................... 3 2.3 Digital Control Interface ...................................................................................................... 3
3. Expansion Interface ................................................................................................................ 3 4. Communications Interface ...................................................................................................... 3
4.1 Logical Information and Transaction Model .................................................................. 3 4.2 – PCT Functions ................................................................................................................... 3 4.3 – PCT Messages and Attributes ............................................................................................ 3
4.3.1 Event Modes .................................................................................................................. 3 4.3.2 Common Data Classes ................................................................................................... 3 4.3.3 Commands to PCT for minimum Title 24 Functionality............................................... 3 4.3.4 Additional Commands to PCT for Joint IOU Functionality .......................................... 3 4.3.5 Two-way functionality................................................................................................... 3
4.4 – PCT Transactions............................................................................................................... 3 4.4.1 – Sequence of events for one way communications enabled systems ........................... 3 4.4.2 – Sequence of events for two way communications enabled systems........................... 3
4.5 RBDS Implementation Profile ........................................................................................ 3 4.6 Two Way Pager Profile................................................................................................... 3
5. Human-Machine Interface ...................................................................................................... 3 5.1 PCT User Interface Requirements Summary........................................................................ 3
5.1.1 Title 24 PCT Code Language Rev 29b .......................................................................... 3 5.1.2 CEC Vision Document .................................................................................................. 3 5.1.3 IOU documents and presentations ................................................................................. 3
5.2 Standardized User Interface .................................................................................................. 3 6. Operational Issues and Expected Behaviors ........................................................................... 3
6.1 – Hold Button Behavior ........................................................................................................ 3 6.2 – Conflicting Message Behavior........................................................................................... 3 6.3 – Illogical Temperature Setpoint Behavior .......................................................................... 3
Annex A – Use Cases ..................................................................................................................... 3 A.1 – PCT Use Cases.................................................................................................................. 3 A.2 – CEC: A Vision of Demand Response 2015 ...................................................................... 3
Annex B – Glossary ........................................................................................................................ 3 Annex C – UC Berkeley PCT Research Report 3
PCT Reference Design TOC
Questions / Comments?
Formed in January 2005 in response to suggestion by the CEC PIER program as an outcome of publication of reference design report
Hosted as a child entity under the UCA International Users Group
OpenAMI accepted CEC reference design document as a starting point
OpenAMI Overview
2005 OpenAMI | www.OpenAMI.org Slide 75
UCAIug Sponsorship of OpenAMI — Justification
• Utility Communications Architecture International Users Group - UCAIug
• UCAIug Mission is to support Utility Communication in general
• Strong connection to IEC and IEEE – fast track to get to IEC international standard – but leave option open for other SDOs as well
• Large pre-existing utility and vendor participation
• Board members were willing to host this group
2005 OpenAMI | www.OpenAMI.org Slide 76
Mission StatementMission Statement
• Foster enhanced functionality, lower costs and rapid market
adoption
of Advanced Metering and Demand Response solutions through the
development of an open standards-based reference design & data
model
ObjectivesObjectives• Facilitate the broad adoption of advanced metering and demand response
• Define what ‘open standards’ means for advanced metering and demand response
• Diminish technical and functional risk concerns for utilities, regulators and rate-payers
• Empower consumers with tools to better understand and manage their energy use
• Foster industry innovation, efficiency and lower cost solutions
OpenAMI Task Force
2005 OpenAMI | www.OpenAMI.org Slide 77
OpenAMI Architecture
UDC AMI DomainAMI Network Domain
Wide Area Network(Private / Public)
AMI Network(Private / Public)
AMI Network Interfaces
Application Interfaces
Metering Systems
· Meter Reading
· Meter Lifecycle Management
· Meter Read Data Warehouse· Data Collection & Processing· Data Retrieval & Publishing· Data Storage & Archive
AMI System Domain
UDC Domain
· Billing
· CRM / CIS
· Distribution Operations
· Planning & Forecasting
· DER Operations
· Field Automation
Application Interfaces
LSE / ESP Domain
· Billing· On-Line Services· Load Aggregation· Planning & Forecasting
Application Interfaces
Regulators Domain
· Oversight· Compliance· Rate Validation· Security and System
Analysis & Audit
Application Interfaces
CAISO Domain
· Dispatch· Grid Management· Price Calculation· Market Operations· Emergency Control· Planning & Forecasting
Application Interfaces
· Billing· Planning & Forecasting
Application Interfaces
Market Bid Generation Provider Domain
Retail Energy Users or their Agents
Domain
· Meter Reading· Meter Lifecycle Management
Application Interfaces
· Building Energy Management· Appliance Control· Load Control (shed / generate)
Customer PremiseSystems & Equipment Domain
ApplicationInterfaces
Thermostat
FanPumpCompressor
GeneratorChiller
· Billing· DER Operations
Application InterfacesDistributed Energy
Resources Domain
PremiseInterfaces
Premise Interfaces
ApplicationInterfaces
AMI Meter Interfaces
AMI Network Interfaces
PremiseInterfaces
AMI Meter / Service Point Domain
AMI Meter Interfaces
Premise Interfaces
AMI Comm Interface
Meter Interface
SRDDisconnectInterface
Meter Service Companies Domain
Well defined points of interoperability,
interfaces, transactions, and
information models
http://www.openami.org/
Questions before proceeding?
UtilityAMI Overview
UtilityAMI Overview
Formed in November 2005 to address lack of utility guidance
Need for requirements to be driven by entities who will buy AMI systems and their components - utilities
UCA International Users Group
UCAIUG Technical Committee
Intelligent Grid Working Group
UtlityAMI Advisory Group
Requirements Task Group
EnterpriseArchitecture Task Group
OpenAMI Task Force
Data Model Task Group
Reference Design Task
Group
Interoper-ability Task
Group
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.
Glossary: Definition of AMI
An advanced metering infrastructure is a comprehensive, integrated collection of devices, networks, computer systems, protocols and organizational processes dedicated to distributing highly accurate information about customer electricity and / or gas usage throughout the utility and back to the customers themselves.
Glossary: Definition of AMI
Such an infrastructure is considered “advanced” because it not only gathers customer data automatically but does so securely, reliably, and in a timely fashion while adhering to published, open standards and permitting simple, automated upgrading and expansion.
Glossary: Definition of AMI
A well-deployed advanced metering infrastructure enables a variety of utility applications to be performed more accurately and efficiently including time-differentiated tariffs, demand response, outage detection, theft detection, network optimization, and market operations.
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 ForceSecurity issues and their relationship to business needs
4. Consumer Interface – HAN Task ForcePolicy for Customer Portal interface to customer end user appliances
5. AMI Network InterfacePolicy for AMI network to MDMS interfacing
6. Back Office Interface – AMI-Enterprise Task ForcePolicy for MDMS to enterprise back office system connectivity
7. General Issues Forum
Common Requirements Document
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.
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
Requirements Voting Results
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)
Status and Next Steps
Task 1 complete Glossary published on collaboration site Web version of glossary accessible to members Technology capability evaluation method published by
SCE (http://www.sce.com/ami/ ) – no longer a UtilityAMI subtask
Common requirements approved August 4, 2006 Task 2 (modular interface) – transferred to
OpenAMI Task 3 (Security) draft scoping document prepared
First meeting this Thursday Task 4 (Consumer Interface) – this workshop! Task 5 (Meter to MDM Interface) – not started Task 6 (MDM to Enterprise Interface) – Coming
soon Other – AMI Vendor Database – online now
HAN Task Force Scope
High level reference design/architecture
Utility Requirements Information Models Security
Stakeholders and Collaborators
Utility driven Vendor input required
Hardware – network, devices Associations – e.g. ZigBee, ZWave,
Etc. Standards Groups
Envisioned Deliverables
HAN Principles and Framework HAN Use Cases HAN Requirements Device Models (or another TF) Security Model (of another TF)
Questions
After the break, we will see what OpenHAN has done to address these objectives
Open Discussion
UtilityAMI OpenHAN TFActivity Summary
HAN Guiding Principles, Use Cases, System Criteria
TF Operating Rules
OpenHAN is a TF of the UtilityAMI WG and operates under the same governing rules
This is a utility driven activity Members in good standing of the UCA
International Users Group which represent a utility are eligible to vote
Utility members are permitted to put any issue on the table for discussion or vote
Any member may contribute / comment A majority of utility members may vote to table
any issue
OpenHAN Overview
Outline:Framework introductionDocumentation PurposeDocumentation ProcessGuiding Principles Functional Characteristics Use Cases System CriteriaNext Steps - Requirements Process
AMI Opportunity for HAN
1000 MW of Peak Demand Response by 20151
0.5% Annual energy conservation effect across all customers1
Enables energy information for customers without internet access Satisfy higher customer experience expectations Ubiquitous deployment provides market catalyst for enabling
energy innovation for customers
Now is the right time• Viable open standards based protocols exist• Incremental HAN in meter cost is <2% of program capital costs • Cost effective based on initial limited use – low financial impact from
risk of stranded technology• If not now – next opportunity for ubiquitous deployment is 15 – 20
years
1. Based on SCE Dec. 2006 preliminary business case analysis, subject to revision
Utility HAN Framework
Based on Strategic Planning and System Engineering
Each level provides direction and context for lower level
Delineates participation and accountability
Can be mapped to GridWise Architecture Framework(Loosely coupled – Decomposition framework vs. Organizational interoperability view)
Stakeholder considerations at every level: regulators, consumers, utilities, vendors
Organizational
Economic | Policy
Objectives | Procedures
Technical
Connectivity
Syntactic | Network
Informational
Context | Semantics
GridWise Interoperability FrameworkHAN Lif
ecycle
Hierarch
y
Value
Proposition
Vision &
Guiding
Principles
Platform
Requirements
(Technology Specific)
System Criteria
Functional C
haracteristic
s
Platform
Independent
Requirements
OpenH
AN
Com
pliant
Use Cases
Communication Specification Example
ValueProposition
Vision &Guiding Principles
Functional Characteristics &
Criteria
Platform Independent Requirements
Platform Requirements (Technology Specific)
openHA
N C
ompliant
- Enable Demand Response- Enable energy information for customers without internet access- Satisfy higher customer experience expectations - Enable energy innovation for customers
- Provide secure two-way communications- Support command and control signaling- Support consumer specific signaling - Support ownership model
- Provide an agile communication capability - Provide adequate capacity - Provide communication reliability - Provide adequate communication control
- Requirements: Shall not interfere with other networks- Requirements: Shall allow coordination/control transfer - Requirements: Shall provide product interoperability - Architecture: Define communication control
- Shall be 802.15.4 (Low Rate WPAN) compliant - Shall be IEEE P1901 compliant- Shall use direct-sequence spread spectrum coding- Shall use deficit weighted round robin (DWRR) for scheduling
Utility Specific
Example Needs and Requirements
Security Specification Example
ValueProposition
Vision &Guiding Principles
Functional Characteristics &
Criteria
Platform Independent Requirements
Platform Requirements (Technology Specific)
openHA
N C
ompliant
- Enable Demand Response- Enable energy information for customers without internet access- Satisfy higher customer experience expectations - Enable energy innovation for customers
- Provide secure two-way communications- Support command and control signaling- Support consumer specific signaling - Support customer ownership model
- Provide a robust cryptographic capability for load control signaling - Provide a cryptographic capability for energy information sharing - Provide a secure device registration and authentication capability- Provide a robust audit capability
- Requirements: Shall use FIPS 197 (AES) for symmetric cryptography- Requirements: Shall use third party materials for authentication - Architecture: Define Commissioning and registration process- Architecture: Define Command and Control Signaling
- Shall use MAC layer security as specified in 802.15.4 - Shall use CCM mode (Counter with CBC-MAC) for block ciphers- Shall fully support EAP-PSK (RFC 4764)- Shall use EAP-TLS, defined (RFC 2716)
Utility Specific
Example Needs and Requirements
OpenHAN Documentation Purpose
Describes utility’s view of HAN Establishes participation scope and scale Intended audience:
Regulators – establish position, clarify roles and responsibility
OpenHAN – creates input for further system refinement (e.g., platform independent requirements, use cases)
Vendors – shows approach, motivation Establishes a baseline Information sharing with other stakeholders
Documentation Process (Ratified)
Utility Specific Value Proposition
Bus
ines
s N
eeds
Business Continuity Needs
Assessment
RegulatoryCompliance
Analysis
Prog
ram
Nee
ds
Common Purpose Common Vision
Indu
stry
Ena
bler
s
Common Principles
CA IOUValidation
Compliance Validation
Use Cases
OpenHAN Vetting and Refinement
System Criteria
OpenHAN Assessment
Platform Independent Requirements and Architecture
Ope
nHA
N D
ocum
enta
tion
Proc
ess
Technology Platforms and Alliances
Aug 15 Ratification Date
Examples: PUC, SOX, NERC, etc.
Ratified
Ratified
HAN Guiding Principles
Value Proposition
Guiding Principles
Use Cases
Platform Independent Requirements
Platform Requirements
(Technology Specific)
System Criteria
HAN Guiding Principles (Ratified 7/11/2007)
Capabilities Supports a secure two way communication with the meter Supports load control integration Provides direct access to usage data Provides a growth platform for future products which leverage HAN
and meter data Supports three types of communications: public price signaling,
consumer specific signaling and control signaling Supports distributed generation and sub-metering
Assumptions Consumer owns the HAN Meter to HAN interface is based on open standards Implementation is appropriate given the value and the cost Technology obsolescence does not materially impact the overall value
HAN Use Cases
Value Proposition
Guiding Principles
Use Cases
Platform Independent Requirements
Platform Requirements
(Technology Specific)
System Criteria
Use Case Scope
Abstracted to highest level for rapid adoption (i.e., more details to follow) note: previous work has been more detailed
Concentrates on Utility to HAN interactions Device ownership independent (e.g.,
registration is the same whether or not the utility supplies the device)
Interactions are based on Utility relevant activities only (Ignores other HAN activities within the premise – e.g., Home Automation)
Required device functionality will be specified in subsequent phases (i.e., platform independent requirements)
Utility/Consumer Interface Architectures Considered
Meter as sole gateway to HAN Support use cases Lowest cost, meets business case Can be implemented over 4 years ubiquitously to all 5 million customers Seen as starting point for eventual shift to customer gateway controlled HAN
Meter as interface to in-home gateway (with protocol converter as needed) Supports use case Higher cost, may require customer knowledge / configuration Seen as eventual end state over life of system
Third party gateway(s) only to load control devices Slow market adoption – could take 10 years to reach 70% market penetration like
internet Does not support near-real time access to energy data from meter at no incremental
cost to customer Security, network management, QOS more challenging If challenges met, compatible with overall architecture Avoids meter interface technology obsolescence
Scenario A: Meter as Gateway
Utility Owned
Consumer Owned
Private Fixed NetworksWAN/LAN
Meter
2-way
T24 PCT
RDS/FM or pager broadcast(disabled when utility network
operational)
1-way
Appliance
Sub-meter
Display Devices
1.e.g., 802.11b, proven mesh LAN protocol, etc.
2-way
• interval energy• time• billing start time• peak power• messages• acknowledgements• price signals• reliability signals
RF-TX1
Third-Party Provider
Scenario B: Evolution to Multiple Gateway Model
Utility Owned
Consumer Owned
Private Fixed NetworksWAN/LAN
Anyintervalmeter
or pole-topcollector
PSTN/DSL/Cable/SatelliteWAN/LAN
2-way 2-way
Any gateway (protocol xfr)
•Special box•Internet modem•Router•Media PC•Security panel• ……..
HAN Protocols³ZigbeeZ-waveInsteon
Wi-FiEIA709
HomePlugBluetooth
2-wayT24 PCT
RDS/FM or pager broadcast
1-way
2-way
HAN access using expansion port
Sub-meter
Appliances
Display Devices
1.e.g., 802.11b, proven mesh LAN protocol, etc.2.To be determined3.Up to 45 active protocols worldwide
Broadband TV, music
2-way
2-way
2-way
• interval energy• time• billing start time• peak power• messages• acknowledgements• price signals• reliability signals
RF-TX1
PLC-TX²and/or
Third-Party Provider
Third-Party Provider
Third-Party Provider
Third-Party Provider
2-way
Ron Hofmann
2-way
Scenario C: 3rd Party Communication Channel/Gateways Only(Out of Scope for OpenHAN)
Utility Owned
Consumer Owned
Private Fixed Networks2
WAN/LAN
Anyintervalmeter
PSTN/DSL/Cable/SatelliteWAN/LAN
2-way
2-way
Any gateway (protocol xfr)
•Special box•Internet modem•Router•Media PC•Security panel• ……..
HAN Protocols³ZigbeeZ-waveInsteon
Wi-FiEIA709
HomePlugBluetooth
2-wayT24 PCT
RDS/FM or pager broadcast
1-way
2-way
HAN access using expansion port
Other
Appliances
Display Devices
1.Utility information to/from utility network2.Up to 45 active protocols worldwide
Broadband TV, music
2-way
2-way
2-way
• interval energy• time• billing start time• peak power• messages• acknowledgements• price signals• reliability signals
Third-Party Provider
Third-Party Provider
Third-Party Provider
Third-Party Provider
Ron Hofmann
utility.com
Use Case Organization
System Management and Configuration Depot Configuration Installation and Provisioning Utility Registration Remote Diagnostics Maintenance and Troubleshooting
Load Control and Energy Management Voluntary Mandatory Opt-out
Energy Management System Energy Storage and Distribution User Information Submetering
System Management and Configuration
Five scenarios Depot Configurations – covers any manufacturer certification or configuration steps
needed for compliance/compatibility Installation and Provisioning - covers the activities associated with physical installation
and the admission to the local HAN Registration - covers the steps necessary admit a device to the Utility AMI network as
well as any high level consumer/device/application enrollments HAN Remote Diagnostics – covers the high level activities associated with utility
diagnostics HAN Device Diagnostics – covers on-site troubleshooting steps
Major assumptions and notes Network provisioning and registration have differing purposes and steps (e.g., network
vs. utility admission, security and directional authentication) Consumer consumption signaling requires registration (confidentiality and privacy) Utility control signaling requires registration Public Pricing does not require registration (i.e., needs one directional trust – network
commissioning) Registration requirements could impact manufacturing/depot configurations (implies
certification process) Mobility requirements are supported but not defined within these use cases (e.g.,
EV/PHEV premise/account/device bindings)
Load and Energy Management
Three Scenarios Voluntary - covers load reduction at the customer’s site by communicating
instantaneous kWh pricing and voluntary load reduction program events to the customer
Mandatory – covers load and energy management scenario refers to demand response resources dispatched for reliability purposes
Opt-out – covers request to opt-our of the program due to a medical emergency/conditions
Assumptions and Notes The HAN device is capable of differentiating between emergency/reliability
and/or price-response event signals. Certain HAN devices can distinguish or support various event types and take
appropriate action based on the event. HAN Devices do not need to register with the Utility AMI system to obtain
Utility messaging (e.g. pricing events). However, the customer must enroll in a demand response program or tariff and must register the HAN device with the Utility for the HAN device to confirm its successful actuation of the event.
HAN Devices receive optional warning messages Mandatory events require gateway acknowledgement
Energy Management System
Covers the utility to EMS interactions Assumptions and Notes
The EMS is aware of or can retrieve the types of HAN device types and the status of those devices connected to the HAN and upon registration or change-out. (e.g., fridge on/off)
EMS controls production, consumption and storage within the HAN. (e.g. Controls charging/discharging of an Electric Vehicle)
The EMS can be pre-programmed to respond to utility signals and commands. (e.g., reliability event)
Use case does not imply the utility’s preferred configuration or communication for reliability programs. (e.g., utility may still require HAN device registration)
Energy Storage and Distribution
Covers the connection interaction of the premise Home Area Network (HAN), the Utility AMI system and the electric system (home, vendor or utility’s).
Assumptions and NotesDependent on Submetering use caseEnergy Supplying Unit (ESU) can be an energy
storage device (e.g., electric vehicle battery) or an energy generation device (e.g., photovoltaic array or backup generator).
Assumes that the Energy Supplying Unit (ESU) already contains energy
User Information
Covers utility initiated messages and electric usage updates via an In Home Display (IHD) – does not cover other internal HAN display functions
Assumptions and NotesRapid updates to any IHD does not restrict AMI or
other utility functionalitiesThe IHD is either pre-programmed to respond
appropriately to price, consumption, load or event messages and/or the customer has manually programmed the IHD
The IHD indicates the status of the communication link with the Utility AMI gateway
Submetering
Covers the measurement of other metering devices within the HAN
Assumptions and Notes: The AMI system supports Sub meter device-specific, consumer-
specific and location-specific rates/billing. (e.g., Electric Vehicle (EV), Plug in hybrid electric vehicle (PHEV)).
AMI system provides pricing information to the sub metering devices.
This use case also applies to other HAN devices with metering capabilities (e.g., other entity gas and/or water meters, EV sub-metering, PV sub-metering, etc.)
This use case assumes multi-lateral information sharing among utility distribution companies (e.g., supports mobility).
Device provides the customer (end user) with the appropriate information. (e.g. % of charge, current rate of consumption, etc)
The device provides the utility AMI gateway with the current energy requirement and task time to completion
Motion for Voting
Move to accept the Load and Energy Mangement,Energy Storage and Generation,System Configuration and Management,User Information,and Energy Management System
HAN use cases as well as the Introduction and Definitions supporting documents submitted by the Use Case Work Team and (as will be amended according to the agreements reached during discussion) as a base set for the purpose of starting the platform/technology independent requirements development process.
OpenHAN Use Cases
Ratified unanimously by the six utilities in attendance 8/15/2007AEPConsumers EnergyEDFPG&ESCESDG&E
Other utilities may ratify after review
HAN System Criteria and Functional Characteristics
Value Proposition
Guiding Principles
Use Cases
Platform Independent Requirements
Platform Requirements
(Technology Specific)
System Criteria
HAN Functional Characteristics and System Criteria
Applications
DirectControl
Cycling Control
Limiting Control
Distributed Generation
Submetering
EnvironmentState
Device State
EnergyCost
Energy Production
Energy Optimization
Energy Demand
Reduction
EnvironmentImpact
UserInput
UserOutput
ControlHuman
MachineInterface
MeasureMonitor
System*
Communications
Discovery Control
Announce
Respond
InitialIdentify
Identify
Authenticate
Configure
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
Initialization
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
*Applies to devices and applications that connect to the AMI Network
Functional Characteristics and System Criteria
Criteria and characteristics provides non authoritative context and clarification Viewed as technology enablers Driven by Guiding principles and use cases Establishes high level technical expectations Organized by behavior and function Includes Application, Communications, Security and Privacy and Performance
Application Criteria Utility functionality Know consumer functionality Application evolution and migration
Communication Criteria Logical and physical communication decoupling (AMI Backhaul and HAN) Interoperability and interference (e.g., customer gateways, networks) Communication evolution
Security and Privacy Graduated model (low, medium, high robustness) based on signal type Authentication, Authorization and Accountability
Authentication material: source, distribution flows Authorization (rights): device registration, participation and revocation Accountability: audit, alerts and non-repudiation
Performance (Adaptability, Flexibility, Scalability, Reliability, etc.) Operations, Maintenance, Logistics
HAN Application Characteristics
Control - Applications that respond to control commands Direct - Turns load On or Off Cycling - Turns load On or Off at configurable time intervals Limiting - Turns load On or Off based on configurable thresholds
Measurement & Monitoring - Applications that provide internal data & status Distributed generation (DG) - Local energy input/output (kWh, kW, other energy values) Sub-metering - Device specific, end-use energy consumption or production (e.g. Consumer PHEV) Environmental State - Current local conditions (e.g., temperature, humidity, time, airflow, ambient light
level, motion) Device State - The current or historical state of the device (e.g., lights/fans/compressor/motor/heater are
on/off) Processing - Applications that consume, process and act on external and internal data. These
applications accept data from external systems and HAN measurement & monitoring applications. In general, these applications that have a higher level of complexity and cost.
Energy Cost - Calculates current and overall energy cost Energy Consumption - Calculates current and overall energy consumption Energy Production - Calculates current and overall energy Production Energy Optimization - Utilizes external and HAN data to determine desired response based on a
consumer configurable profile Energy Demand Reduction - Uses external and HAN data to reduce load based on a consumer
configurable profile Environmental Impact - Calculates environmental impact of current energy consumption (e.g. Power
Generation Plant CO2 emissions related to consumer specific load) Human Machine Interface (HMI) - Applications that provide local user input and/or output.
These applications are based constrained and based on the data type User Input - Provides consumers with a means to input data into an Application (e.g., Touch screen,
Keypad) User Output - Provides an Application with a means to output data to the consumer (e.g., In-Home
Display, text message)
HAN Communications
Discovery - The identification of new nodes within the HAN Announcement – both active and passive device notification methods Response - Includes both endpoints (e.g., announcing entity and recipient
entity) Initial Identification - Device-type and address identification
Commissioning - The network process of adding or removing a node on the HAN with the expectation that the system is self-organizing (i.e., initial communication path configuration). This process is decoupled from utility registration. Identification - Uniquely identifying the device Authentication - Validation of the device (e.g., the network key) Configuration - Establishing device parameters (e.g., network ID, initial path,
bindings) Control Autonomous functions enabled by the platform specific
technology Organization - Communication paths (e.g., route) Optimization - Path selection Prioritization - Communication based on importance (e.g., queuing,
scheduling, traffic shaping) Mitigation - Ability to adapt in response to interference or range constraints
through detection and analysis of environmental conditions
HAN Security
Access Controls and Confidentiality – protection methods associated with both data-at-rest and data-in-transit based on data type Public Controls (low robustness) - protection methods for publicly available information
(e.g., energy price) Private Controls (medium robustness) - protection methods for confidential or sensitive
data (e.g., consumer usage) Utility Controls (high robustness) - protection methods for utility accountable data (e.g.,
load control, sub-metering data) Registration and Authentication – Verifying and validated HAN participation
Initialization – establishes the application/device as a validated node (i.e., logical join to the utility’s network)
Validation – validates the application’s data (i.e., request or response) Correlation – correlating an account (e.g., consumer) with a device, application or
program (e.g., DR programs, peak time rebate, etc.) Authorization – rights granted to the applications Revocation – removing an established node, correlation or authorization
Integrity – Preserves the HAN operating environment Resistance – methods which prevent changes to the application or application’s data
(e.g., tamper and compromise resistance) Recovery – restores an application or the application’s data to a previous or desired state
(e.g., reloading an application, resending corrupted communications) Accountability – monitoring malicious activities
Audit – application log detected compromise attempts Non-repudiation – applications and application operators are responsible for actions
(e.g., can not deny receipt or response)
HAN Performance
Availability - The applications are consistently reachable
Reliability - The applications are designed and manufactured to be durable and resilient
Maintainability - The applications are designed to be easily diagnosed and managed
Scalability - The system supports a reasonable amount of growth in applications and devices
Upgradeability - The applications have a reasonable amount of remote upgradeability (e.g., patches, updates, enhancements)
Quality - The applications will perform as advertised
HAN Operations, Maintenance and Logistics
Manufacturing and Distribution - Vendor’s pre-installation activities Pre-commissioning - Depot level configuration setting Registration configuration - Any required utility specific
configurations Labeling - Utility compliance and standards labeling Purchasing - Supports multiple distribution channels (e.g., retail,
wholesale, utility) Installation - physical placement of the device
Documentation - Installation materials and manuals Support Systems - Installation support systems including web
support, help line, other third party systems Management and Diagnostics
Alarming and logging - Event driven consumer and utility notifications
Testing - System and device testing Device reset - Resets the device to the installation state
HAN Platform Independent Requirements
Value Proposition
Guiding Principles
Use Cases
Platform Independent
Requirements
Platform Requirements
(Technology Specific)
System Criteria
Requirements Process Proposal
Determine Participation and Responsibility Review relevant use case(s) Review system criteria and organizing framework For each level four category generate basic platform independent
requirements For each level four category generate advanced (optional)
platform independent requirements Record motivating use case for fine-grain traceability (coarse
traceability is inherent in the process) Organization of Each Section:
Context (Overview, Architectural Drawings, Application of Requirements, etc.)
Basic Requirements Advance Requirements
Use OpenHAN TF Vetting Process
Requirements Process Proposal (continued)
Applications
ControlHuman
MachineInterface
MeasureMonitor
Registration
Communications
Discovery Control
Security PerformanceOperations
MaintenanceLogistics
Availability Reliability Maintain-
ability
Le
vel 2
Le
vel 3
Use
Ca
se
Integrity Account-
abilityRegistration
Authentication
AccessControl
Confidenti-ality
Installation ManufactureDistribute
Manage Maintain
CommisionProcessing
Installation and Provisioning
Depot Configuraiton
Maintenance and Troubleshooting
Remote Diagnostics
Le
vel 4
See System Criteria for Level 4 Details
Bas
icA
dv
anc
ed
Req
uir
emen
ts
Requirements Analysis
Submetering
User Information
Load and Energy Management
EMS
Energy Storage and Distribution
Next Steps
Develop OpenHAN platform independent requirements Ratify Requirements Continue to share information with technology
communities (i.e., vendors, alliances) Provide advice and guidance to working groups and
task forces of OpenAMI and UtilityAMI working on specific technology mappings and applications guidelines (e.g. information models, security profiles, communication profile mappings)
General Discussion
We need feedback Does the process make sense? How do you see the HAN evolving? What industry do you see driving the
HAN? How do multiple HAN’s co-exist and
cooperate – or stay out of each others way?
Is what we have done so far useful? What use cases (scenarios) are
missing?
Questions before proceeding?
AMI / DRI Security
AMI Security – Statement of Objectives
“AMI Security must facilitate the easy exchange of high resolution electric load and usage data between the customer and the utility while maintaining customer privacy and protecting critical infrastructure”
Do the NERC CIP Standards Apply to AMI?
The answer to this revolves around two key issues: Definition of Critical
Infrastructure Placement of Electronic
Security Perimeter
Do the NERC CIP Standards Apply to AMI?
CIP-002-1 Critical Cyber Asset Identification dictates that the utility will use a risk-based assessment to identify Critical Assets.
The requirement relevant to AMI is the following item: R1.2.5. Systems and facilities critical to
automatic load shedding under a common control system capable of shedding 300 MW or more.
Questions before proceeding?
Title 24 PCT Security
California Title 24California Title 24
Building Code Update for 2008Building Code Update for 2008 Requires installation of PCTs for new Requires installation of PCTs for new
constructionconstruction Purpose is to ensure a baseline resource for Purpose is to ensure a baseline resource for
demand responsedemand response Utilizes a California wide communications Utilizes a California wide communications
infrastructureinfrastructure IOUs can utilize their own AMI network IOUs can utilize their own AMI network
insteadinstead
PCT SecurityPCT Security
Programmable Communicating ThermostatProgrammable Communicating Thermostat Dovetails into AMIDovetails into AMI Designed to work “stand-alone” (one-way Designed to work “stand-alone” (one-way
communications)communications) Mandated by law in CaliforniaMandated by law in California
IssuesIssues Needs to work to enable Demand-ResponseNeeds to work to enable Demand-Response Must authenticate broadcast signalsMust authenticate broadcast signals Distributed through variety of channelsDistributed through variety of channels Resource-constrained platformResource-constrained platform
Fundamental Strategic ObjectivesFundamental Strategic Objectives
ResistanceResistance Protect Access and ControlProtect Access and Control
ResilienceResilience Limit Damage and LossLimit Damage and Loss
RecoveryRecovery Regain Confidence in Safe, Regain Confidence in Safe,
Reliable OperationReliable Operation
AssumptionsAssumptions
Human FactorsHuman Factors Organizational Lapses, Honest Error, MaliceOrganizational Lapses, Honest Error, Malice
Practical RecoveryPractical Recovery Replacement / Repair Costs, Negative PublicityReplacement / Repair Costs, Negative Publicity
Security PrioritiesSecurity Priorities 1) Authentication, 2) Message Integrity1) Authentication, 2) Message Integrity
Distribution ChannelsDistribution Channels Manufacturers, Utilities, Retail ChannelsManufacturers, Utilities, Retail Channels
FeedbackFeedback Error Codes, Serial/Model #, Customer Info, Date/Time/LocError Codes, Serial/Model #, Customer Info, Date/Time/Loc
Risk Management ApproachRisk Management Approach
VulnerabilitiesVulnerabilities Frequency x SeverityFrequency x Severity
MappingMapping Threats through Threats through
Vulnerabilities to AssetsVulnerabilities to Assets MitigationMitigation
Reduce, Transfer, AcceptReduce, Transfer, Accept
AssetsAssets Value, Sensitivity Aspect (C-I-A)Value, Sensitivity Aspect (C-I-A)
ThreatsThreats Possible Source, Intent, StrengthPossible Source, Intent, Strength
Possible AttacksPossible AttacksApplication LayerApplication Layer Sudden LoadSudden Load Recall Authentic SignalRecall Authentic Signal Load ShedLoad Shed Software DownloadSoftware Download False AcknowledgementFalse Acknowledgement False Time SynchFalse Time Synch False Display MessagesFalse Display Messages Gaming the SystemGaming the System
Transport LayerTransport Layer Control of Head-End Radio Control of Head-End Radio
SystemSystem DoS Head-EndDoS Head-End Interception of Wireless Interception of Wireless
MessageMessage
Physical LayerPhysical Layer Signal Jamming / False Signal Jamming / False
MessagesMessages Ground Station or VehicleGround Station or Vehicle Balloon / AircraftBalloon / Aircraft
Customer Disables Customer Disables Thermostat AntennaThermostat Antenna
Possible AttacksPossible Attacks
Non-Cryptographic Mitigation MethodsNon-Cryptographic Mitigation Methods
PrinciplesPrinciples Time As Ally – Slow the AttackTime As Ally – Slow the Attack Limit Allowable BehaviorLimit Allowable Behavior Detection As Well As PreventionDetection As Well As Prevention
Business LogicBusiness Logic Acceptable Commands, Random Delay On Acceptable Commands, Random Delay On
Cancel, Hard Limits, Time SynchCancel, Hard Limits, Time Synch Detection and EnvironmentDetection and Environment
IDS, Heartbeat, Historical Data, Tamper DetectionIDS, Heartbeat, Historical Data, Tamper Detection
Non-Cryptographic Mitigation MethodsNon-Cryptographic Mitigation Methods
System Recommendations
IDS
Frequent Time Update
Logical Gaming Detection
Tamper Detection
External Factors / Influence
Incentives
Legislation
Crypto Algorithm
Key Administration
Asymmetric Keys
Key Splitting
Key Distribution
Key Management
KEYS & CRYPTO
Compromise Head-End
Jam Broadcast Signal
Falsify / Forge Data
Disable Antenna
Locally Change PCT Time
ATTACK MECHANISM DETECTION
Radio Stations
FCC
ENVIRONMENT
Layers of Defense
No Remote Load Increase
Safety Limits
Random Recovery Delays
Initial Setback Recovery Limit
Override Local Time Set
Simultaneous Addressing Limits
BUSINESS LOGIC
Audit Logs
Message ContentMessage Content
TimestampTimestamp Message IdentifierMessage Identifier
Use cryptographic nonce principlesUse cryptographic nonce principles PCT remembers most IDs usedPCT remembers most IDs used
Valid range only slightly larger than PCT memoryValid range only slightly larger than PCT memory Difficult to guess unused IDDifficult to guess unused ID
Timestamp + ID Timestamp + ID Unique Content Unique Content Regardless of instructionRegardless of instruction Complimented by use of an HMACComplimented by use of an HMAC
Cryptographic Mitigation ApproachesCryptographic Mitigation Approaches
Secret Sharing (a.k.a. “Key Splitting”)Secret Sharing (a.k.a. “Key Splitting”)Asymmetric CryptographyAsymmetric Cryptography
Registration Registration Use CaseUse Case
1.1. InstallerInstaller retrieves random number from retrieves random number from PCTPCT..2.2. InstallerInstaller contacts contacts System OperatorSystem Operator via out-of-band channel. via out-of-band channel.3.3. InstallerInstaller relays relays PCTPCT random number to random number to System OperatorSystem Operator..4.4. System OperatorSystem Operator relays relays PCTPCT random number to random number to System System
OwnerOwner..5.5. System OwnerSystem Owner performs two XOR operations: performs two XOR operations:
With With PCTPCT random number and random number and System Owner’sSystem Owner’s primary primary public keypublic key
With With PCTPCT random number and random number and System Owner’sSystem Owner’s backup backup public key.public key.
6.6. System OwnerSystem Owner sends results of XOR operations to sends results of XOR operations to System System OperatorOperator..
7.7. System OperatorSystem Operator performs XOR operation with performs XOR operation with PCTPCT random random number and number and System Operator’sSystem Operator’s public key. public key.
8.8. System OperatorSystem Operator transmits registration signal including the transmits registration signal including the labeled results of all three XOR operations to labeled results of all three XOR operations to PCTPCT..
9.9. PCTPCT performs XOR operation with its random number and performs XOR operation with its random number and each of the three result numbers received via registration each of the three result numbers received via registration signal, recovering three labeled public keys.signal, recovering three labeled public keys.
10.10. System OwnerSystem Owner encrypts activation message with encrypts activation message with System System Owner’sOwner’s primary public key. primary public key.
11.11. System OwnerSystem Owner sends (encrypted) activation message to sends (encrypted) activation message to System OperatorSystem Operator..
12.12. System OperatorSystem Operator encrypts activation message with encrypts activation message with System System Operator’sOperator’s private key. private key.
13.13. System OperatorSystem Operator transmits (double encrypted) activation transmits (double encrypted) activation message to message to PCTPCT..
14.14. PCTPCT decrypts activation message: first with decrypts activation message: first with System System Operator’sOperator’s public key; second with public key; second with System Owner’sSystem Owner’s primary primary public key.public key.
15.15. PCTPCT activates. activates.
Key ManagementKey Management
Sole purpose of Sole purpose of Backup key would Backup key would be to distribute be to distribute new Primary key.new Primary key.
Operator keys Operator keys may represent may represent regions, regions, substations, substations, territories, etc…territories, etc…
Remaining IssuesRemaining Issues
Finalize AlgorithmsFinalize Algorithms ECC RecommendedECC Recommended Hashing, Key Wrapping Still To Be Hashing, Key Wrapping Still To Be
DeterminedDeterminedFinalize Number of Levels, Groups of Finalize Number of Levels, Groups of
KeysKeysDetermine Frequency of Time Signal / Determine Frequency of Time Signal /
Heartbeat MessageHeartbeat Message
Final DiscussionFinal Discussion
What have we missed?What have we missed?You can contributeYou can contribute
UtilityAMI – General RequirementsUtilityAMI – General Requirements OpenHAN – HAN RequirementsOpenHAN – HAN Requirements AMI-SEC – Security Geeks OnlyAMI-SEC – Security Geeks Only AMI-Enterprise – SOA for MDMS / CISAMI-Enterprise – SOA for MDMS / CIS OpenAMI – Vendors building stuffOpenAMI – Vendors building stuff OpenPCT – Title 24 implementationOpenPCT – Title 24 implementation
For any additional information, please do not hesitate to contact us Erich W. Gunther
EnerNex Corporation Phone: 865-691-5540 ext. 114
http://www.utilityami.org/http://sharepoint.ucausersgroup.org/http://sharepoint.ucausersgroup.org/openami/http://sharepoint.ucausersgroup.org/openhan/http://sharepoint.ucausersgroup.org/utilityami/amisec/
Contact Us