**REFERENCE DESIGN**

**For Programmable Communicating Thermostats**

**Compliant with Title 24-2008**

Version 1.00

March 26, 2007

Editor: Erich W. Gunther (<erich@enernex.com>)

**Table of Contents**

[1. Introduction 4](#introduction)

[1.1 The Title 24 PCT Code Language (Rev 29f)
4](#the-title-24-pct-code-language-rev-29f)

[1.2 The Virtual Operation Model for Thermostats
6](#the-virtual-operation-model-for-thermostats)

[1.2.1 Required Functional Resources 7](#required-functional-resources)

[1.2.2 Required Functional Behavior 8](#required-functional-behavior)

[2. The HVAC System Interface 11](#the-hvac-system-interface)

[2.1 Minimal Direct Control Interface
11](#minimal-direct-control-interface)

[2.2 Advanced Thermostat Direct Control Interface
12](#advanced-thermostat-direct-control-interface)

[2.3 Digital Control Interface 13](#digital-control-interface)

[3. Expansion Interface 15](#expansion-interface)

[4. Communications Interface 17](#communications-interface)

[4.1 Logical Information and Transaction Model
17](#logical-information-and-transaction-model)

[4.2 PCT Functions 18](#pct-functions)

[4.3 PCT Messages and Attributes 18](#pct-messages-and-attributes)

[4.3.1 Event Modes 19](#event-modes)

[4.3.2 Common Data Classes 19](#common-data-classes)

[4.3.3 Message Commands for Minimum Title 24 PCT Functionality
21](#message-commands-for-minimum-title-24-pct-functionality)

[4.4 PCT Transactions 23](#pct-transactions)

[4.5 Implementation Profiles 25](#implementation-profiles)

[4.6 Security 25](#security)

[4.6.1 Fundamental, Strategic Objectives
25](#fundamental-strategic-objectives)

[4.6.2 Assumptions 25](#assumptions)

[4.6.3 Risk Management Approach 27](#risk-management-approach)

[4.6.4 Possible Attacks 27](#possible-attacks)

[4.6.5 Non-Cryptographic Mitigation Methods
29](#non-cryptographic-mitigation-methods)

[4.6.6 Message Content 31](#message-content)

[4.6.7 Cryptographic Mitigation Approaches
32](#cryptographic-mitigation-approaches)

[4.6.8 Remaining Issues 38](#remaining-issues)

[5. Human-Machine Interface 39](#human-machine-interface)

[5.1 Terminology 39](#terminology)

[5.2 Next Steps and Issues to be Resolved
40](#next-steps-and-issues-to-be-resolved)

[5.2.1 Interaction with "Hold" Functions
40](#interaction-with-hold-functions)

[5.2.2 Recovery from "Off" State within an Active Event
40](#recovery-from-off-state-within-an-active-event)

[5.2.3 Standardization of Colors, Indicators, and Icons
40](#standardization-of-colors-indicators-and-icons)

[Annex A: PCT Use Cases 44](#annex-a-pct-use-cases)

[Annex B: Glossary 48](#annex-b-glossary)

[Annex C: UC Berkeley PCT Research Report
50](#annex-c-uc-berkeley-pct-research-report)

[Annex D: Other Publications 51](#annex-d-other-publications)

[Annex E: Title 24 Language (Final Draft -- Rev 29f)
52](#annex-e-title-24-language-final-draft-rev-29f)

[Annex F: The PCT Vision Document and Related Scenarios
54](#annex-f-the-pct-vision-document-and-related-scenarios)

[Eliminating the Need for Rotating Outages through Statewide
Air-Conditioning Load Control with Programmable Communicating
Thermostats (PCTs)
54](#eliminating-the-need-for-rotating-outages-through-statewide-air-conditioning-load-control-with-programmable-communicating-thermostats-pcts)

[Scenario 1- Residential, Low User, Minimum Functionality, Special
Exemptions
58](#scenario-1--residential-low-user-minimum-functionality-special-exemptions)

[Scenario 2 - Residential, High User, High End Options, Advanced
Functionality
70](#scenario-2---residential-high-user-high-end-options-advanced-functionality)

[Scenario 3 - Large Commercial / Industrial
76](#scenario-3---large-commercial-industrial)

[Scenario 4 -- Utility Company 80](#scenario-4-utility-company)

[Scenario 5 -- California ISO 82](#scenario-5-california-iso)

[Scenario 6 -- California Public Utilities Commission
85](#scenario-6-california-public-utilities-commission)

[Annex G: Material related to Joint IOU PCT Specifications using Two-Way
Communications for Extended Functionality
89](#annex-g-material-related-to-joint-iou-pct-specifications-using-two-way-communications-for-extended-functionality)

[Annex G1: Digital Control Interface
90](#annex-g1-digital-control-interface)

[Annex G2: Reliability Event Commands
91](#annex-g2-reliability-event-commands)

[Annex G3: Message Commands for Joint IOU PCT Functionality using
Two-Way Communications
92](#annex-g3-message-commands-for-joint-iou-pct-functionality-using-two-way-communications)

[Annex G4: Message Responses for Joint IOU PCT Functionality using
Two-Way Communications
94](#annex-g4-message-responses-for-joint-iou-pct-functionality-using-two-way-communications)

# Introduction

This document provides a Reference Design for a programmable
communicating thermostat (PCT) that is compliant with the 2008 Update to
the Title 24 Building Energy Efficiency Standards. The Reference Design
focuses on four interfaces that the CEC has determined must be supported
by all PCTs:

1.  HVAC System Interface

2.  Communications Interface

3.  Expansion Interface

4.  Human-Machine Interface

Sections within this document address each interface in terms of its
hardware and software characteristics. In general and unless otherwise
specified, this reference design is compatible with NEMA Standards
Publication DC 3-2003 -- "Residential Controls -- Electrical
Wall-Mounted Thermostats".

In particular, note that the Communications Interface is defined as a
set of logical services that may be performed either over the mandatory
wide area communications interface (e.g. Radio Broadcast Data System
-RBDS- or paging system) of the PCT, or over an optional external
physical network interface connected to the Expansion Interface.

These interfaces are designed to permit a variety of intended uses for
PCTs that have been defined in other publications (see references in
Annex D). To the extent possible, this document strives to be upward
compatible with related efforts underway (e.g. the Joint CA IOU PCT
effort) that intend to construct extended capabilities on the Title 24
foundation. Upward compatibility will be facilitated by not specifying
any capability or feature that can be foreseen to contradict or impede
the clear direction of those related efforts.

The reference design specified in this document is compatible with the
architectural principles set forth in the CEC PIER Strawman Reference
Design for Demand Response Information Exchange[^1].

## The Title 24 PCT Code Language (Rev 29f)

This Reference Design document is guided principally by the content of
Title 24 (rev 29f / final draft), the California legislative code
defining mandated use of Programmable Communicating Thermostats (PCTs).

The following is a summary of requirements affecting PCT product design
and use that this Reference Design document has interpreted from Title
24. The full text of Title 24 appears in Annex E.

-   PCTs shall provide a customer-settable *temperature setpoint* for
    heating and a customer-settable *temperature setpoint* for cooling
    (as applicable to the local HVAC capabilities) for each of four or
    more time periods spanning each 24-hour day. These settings, in
    conjunction with customer use of other supplier-determined features
    and options, will determine how the thermostat operates in the
    absence of price events and emergency events.

-   PCTs shall provide a customer-settable *temperature offset* for
    heating and a customer-settable *temperature offset* for cooling (as
    applicable to the local HVAC capabilities). The appropriate offset
    shall be used by a PCT to make a temporary adjustment to the
    prevailing, customer-programmed temperature setpoint during price
    events, unless an event is specifically overridden by the customer.

> PCTs shall be shipped with default offsets of +4^o^F for cooling and
> -4^o^F for heating. These shall also be reinstated anytime a device
> reset occurs. These default offsets shall remain in effect until the
> customer changes the settings.

-   PCTs shall provide a clock mechanism for coordinating transitions of
    temperature setpoints, responding to events, and measuring delay
    times.

-   PCTs shall provide a non-removable communications capability that is
    compatible with the default statewide Demand Response (DR)
    communications system *(to be determined)*. The default
    communications system will be one-way, whereby utilities issue
    messages to PCTs. Utilities shall use the default communications
    system to notify customer PCTs about price events and emergency
    events.

> A *price event* is issued when energy supplies become tight when
> compared with energy demand. Each customer PCT receiving a price event
> may use the pre-programmed *temperature offset* (described above) to
> lower energy usage for the event's duration. In such cases, the PCT
> uses the temperature offset to temporarily adjust the prevailing
> *temperature setpoint* (described above). A customer is allowed to
> selectively override individual price events, so that no adjustment in
> operation is made. Price events last for a specified period of time,
> which may vary for individual events, unless cancelled by the utility
> before that time has expired. Once a price event has expired or is
> cancelled, the PCT shall continue enforcing the event constraints on
> temperature for a random period of time ranging from 0 to 30 minutes.
> This eases system recovery. In the future, once a smart meter has been
> installed at the customer's premises, energy charges may be raised
> during price events to reflect higher energy costs that the utility
> must pay to increase energy supply.
>
> An *emergency event* is issued when energy system reliability problems
> require a curtailment of residential energy use through temporary
> adjustment of thermostat settings. Emergency events may be used to
> either impose a *utility-specified temperature setpoint* or impose a
> *utility-specified temperature offset* to the customer's prevailing
> temperature setpoint. Customers and their PCTs must involuntarily
> comply with these directives, and customer-initiated changes to
> thermostat settings are not allowed to go into effect while an
> emergency event is in progress. Emergency events last for a specified
> period of time, which may vary for individual events, unless cancelled
> by the utility before that time has expired. Once a price event has
> expired or is cancelled, the PCT shall continue enforcing the event
> constraints on temperature for a random period of time ranging from 0
> to 30 minutes. This eases system recovery.

-   PCTs shall provide capability for the installer (or user) to enter
    some input to the PCT during or after installation to establish
    addressing. The required input could be a character string provided
    by customer service that locates the PCT within the system and
    establishes desired programming options. It's also possible that
    such inputs could be provided through a memory card inserted into
    the PCT's Expansion Port.

-   Aside from the default communications capability, PCTs shall provide
    three other interfaces as described below:

> HVAC Interface: This interface provides connection to 24 Vac power
> (for the PCT) and connections to HVAC equipment controlled by the
> thermostat. The minimum interface is a standardized, 9-position
> terminal block. It must support heat pumps with resistance heat strips
> and a reversing valve in both residential and small commercial units.
>
> Expansion Interface: This shall be an industry-standard interface.
> Insertion of a utility-specific communications module shall disable
> the default statewide communications hardware built into the PCT until
> the module is either removed or no longer receives a signal. This
> interface may be used for other purposes as well, such as additional
> memory.
>
> Human-Machine Interface: This interface provides display and control
> capabilities supporting customer-interaction. Customers require it for
> (a) entering thermostat and time settings, (b) viewing event
> information, communications status, and maintenance-related
> information, and (c) using other features provided by the PCT
> supplier.

-   Certain specified types of HVAC equipment are not required to comply
    with Title 24. Consult the full Title 24 text in the annex,
    referencing Exceptions 1 and 2 to Section 150(i).

## The Virtual Operation Model for Thermostats

The *virtual operation model for thermostats* is an operational
representation of a class of devices used to monitor, control, and
automate the operation of external heating, ventilation, and air
conditioning (HVAC) system components. It is virtual in the sense that
it represents the *functional resources* and *behavior* required of such
devices without prescribing any particular form of implementation. That
said, compliance with specific standards may be necessary to meet
regulatory or interoperability requirements.

Because there is a wide range of product possibilities and expectations,
a virtual operation model (VOM) for PCTs needs to be developed around a
core statement of requirements. For this document, that statement is
framed by the CEC's Title 24 Code Language for PCT devices. The result
is called the *Title 24 PCT* *VOM (Virtual Operation Model for
Programmable Communicating Thermostats Compliant with Title 24-2008).*

An integral part of the VOM for PCTs is an abstract description of the
essential human interface characteristics required by Title 24 code. As
long as they conform to these characteristics and the other VOM
requirements, suppliers may design their PCT products with confidence,
providing any additional features they choose. The only remaining
prerequisite is that the VOM be accepted by the user and supplier
communities. Finally, note that the VOM may also be used as a tool for
developing an information model to support data communications, if
appropriate.

It is expected that this model can and will be expanded in a consistent
manner (as specified in a separate document) to meet the objectives set
forth by the Joint CA IOUs. Those objectives envision use of two-way
communications in lieu of the one-way communications specified by the
Title 24 requirements.

Beyond complying with this model, suppliers are free to extend their
designs in any manner they see fit. Users, on the other hand, will be
free to choose the products that best meet their needs.

The Title 24 PCT VOM is described in the two subsections that follow.

### Required Functional Resources

The following PCT functional resources are either implicitly or
explicitly required by the Title 24 PCT Code Language (refer to Section
1.1):

-   A default, non-removable, **one-way** **communications device** that
    is compatible with the statewide DR communications system (to be
    determined).

-   An industry-standard **Expansion/Communication port**.

    -   This port is available to be used by either a memory module or a
        module supporting two-way communications with the statewide DR
        communications system (to be determined). Refer to Section 3 for
        more information.

-   An industry-standard **display facility** that shall be used to
    display the following:

    -   The current **communications status**, indicating whether status
        is normal or abnormal (always displayed).

    -   The **type of event in progress**: Emergency event, price event,
        or no event (always displayed).

    -   **Maintenance-related information**: Icons and/or error codes
        (always displayed).

    -   The **current temperature** (always displayed)

    -   **Thermostat settings** (under customer control)

    -   **Hex character strings** (as they are entered by a customer or
        installer to represent the PCT's system address, elected DR
        options, and possibly a public security key). Such strings may
        be 26 characters long (perhaps extended to 28 for convenience);
        it is recommended that these strings be broken into 4 character
        fields separated by spaces to aid readability and verification.

-   One or more **setting mechanism(s)** that allow a customer to change
    the following **thermostat settings** at any time *except during
    emergency events*:

    -   A **temperature setpoint** and associated **starting time\
        **(used during normal operation).

> The PCT shall provide a separate pair of parameters for at least four
> operating periods that collectively govern thermostat operation during
> the 24-hour day.

-   **Temperature offsets** (used during price events)

> The PCT shall provide one price-event offset for heating. The PCT
> shall be shipped with a default value of -4^o^F. Only negative values
> are allowed.
>
> The PCT shall provide one price-event offset for cooling. The PCT
> shall be shipped with a default value of +4^o^F. Only positive values
> are allowed.

-   An **entry mechanism** for **hex character strings,** used to
    represent the PCT's system address, elected DR options, and possibly
    a public security key.

-   A **clock mechanism** that allows the PCT to execute temperature
    setpoints scheduled by the customer and to respond to events.

-   A data entity representing the **currently sensed temperature**.

### Required Functional Behavior

The following describes how the PCT needs to behave and use the
functional resources specified above to comply with Title 24
requirements.

-   **One-Way Communications Device**

> The PCT shall receive incoming messages from the statewide DR
> communications system through its one-way communications device. The
> PCT shall follow the instructions in those messages to perform
> temperature control during price events and emergency events.

-   A PCT shall be addressable by utility, area, substation, feeder,
    billing point, or demand response (DR) program.

-   A PCT shall automatically disable operation of the default, one-way
    communications device if a communications module occupies the
    Expansion Interface and the PCT detects a received communications
    signal.

```{=html}
<!-- -->
```
-   **Clock Operation**

> The clock mechanism enables the PCT to execute temperature setpoints
> scheduled by the customer. It also supports other timing functions
> (e.g. start- and stop-time coordination for events; delay measurements
> after events expire).
>
> Accuracy to a precision of one minute is acceptable for this operating
> environment and the applications being considered.
>
> The PCT clock may be set and resynchronized by two means: (1) through
> system communications messages and (2) by the customer, using the
> PCT's human interface. Such action by either source will override a
> prior setting, regardless of which source set it. So in practice they
> override each other, an approach that serves the needs of the system
> and the customer in a balanced way. Either method may be used at any
> time, although the system will likely do so infrequently, one to four
> times a day. One system update time should be 2 AM, as that is
> frequently the official time used for changes to and from
> daylight-savings time.
>
> The system may also elect to update PCT clocks just prior to an event
> and perhaps at intervals during an event, to prevent customers from
> gaming the system.

-   **Normal Operation**

> Normal operation is defined to be the PCT's *prevailing mode of
> operation* as determined by the customer's prior settings and use of
> features[^2] provided by the PCT vendor's design. Aspects of normal
> operation may be modified or interrupted while price events or
> emergency events are in progress, but only to the extent required by
> those events.
>
> To the extent such actions are not prohibited by event requirements or
> the PCT vendor's design, a customer may change PCT settings or use
> other features of a PCT vendor's design during an event. Those changes
> may alter what is considered to be the *prevailing mode of operation*
> when an event is terminated and the PCT returns to normal operation.
>
> The PCT is mandated to provide a mode of operation whereby it controls
> temperature by following the scheduled temperature setpoints. *Because
> price events and emergency events use this mode, the PCT shall require
> the customer to provide initial settings for temperature setpoints
> covering the full 24-hour day and temperature offsets (heating and
> cooling, as applicable) before PCT operation is allowed to commence.
> This requirement shall be re-imposed following any loss of PCT
> settings.*

-   **Price Events**

> Upon receiving a price-event signal, the PCT shall normally adjust the
> *currently applicable* temperature setpoint by the number of degrees
> indicated in the temperature offset (heating or cooling, as
> appropriate) for the duration of the event.
>
> Exception: Title 24 allows a customer to override any individual price
> event through use of an override function provided by the PCT vendor's
> design. If so used by a customer, the override shall be reset when the
> PCT returns to normal operation.
>
> Summarizing, price events only constrain the operating range of the
> thermostat. They do not otherwise affect the operation and use of
> features provided by the vendor's design.
>
> When the price event expires, the PCT shall return to normal operation
> after a delay. The delay shall randomly occur between 0 and 30
> minutes, determined by a process that yields a uniform distribution of
> return times for a large number of PCTs.

-   **Emergency Events**

> Upon receiving an emergency signal, the PCT shall respond to commands
> contained in the emergency signal, including (a) adjusting the PCT's
> *currently applicable* temperature setpoint with a signal-specified
> offset or (b) overriding the PCT's *currently applicable* temperature
> setpoint with a signal-specified temperature setpoint.
>
> A PCT vendor's design may allow customers to specify new thermostat
> settings (i.e. temperature setpoints and temperature offsets) during
> emergency events, but the new settings shall not take effect until the
> PVT returns to normal operation. In such cases, it is the vendor's
> responsibility to determine how prevailing and pending settings are
> displayed.
>
> *Protective rules for remotely operating thermostats:*

-   For *heating*, a PCT shall ignore an emergency signal that specifies
    a *temperature setpoint* higher than the prevailing temperature
    setpoint entered by the customer.

-   Similarly for *cooling*, a PCT shall ignore an emergency signal that
    specifies a temperature setpoint lower than the prevailing
    temperature setpoint entered by the customer.

-   Any *temperature offset* provided by an emergency signal shall be
    specified as an unsigned value and always interpreted by a PCT as a
    change to the *prevailing temperature setpoint* in the direction
    that saves energy, regardless of whether heating or cooling mode is
    in effect.

> This deals with the situation where some PCTs receiving an emergency
> signal are heating and others are cooling, particularly where the PCTs
> reside in different microclimates.

-   Additionally, thermostats shall not be remotely set above (TBD)^o^F
    or below (TBD)^o^F. This measure protects customer premises from
    extreme temperatures that might otherwise be imposed using emergency
    offsets, should the customer already have a very high or low
    temperature setpoint in effect.

> Summarizing, emergency events only constrain the operating range of
> the thermostat and prevent the customer from putting new thermostat
> settings (i.e. temperature setpoints and temperature offsets) into
> effect while an event is in progress. They do not otherwise affect the
> operation and use of features provided by the vendor's design.
>
> When an emergency event expires, the PCT shall return to normal
> operation after a delay. The delay shall randomly occur between 0 and
> 30 minutes, determined by a process that yields a uniform distribution
> of return times for a large number of PCTs.

# The HVAC System Interface

The physical connector on the PCT to be presented to the HVAC system
shall be one or two industry standard screw terminal block headers for
direct control applications. Future versions of this reference design
will require a new connector design allowing easy installation/removal
by the end user. Alternatively, a PCT may present a digital interface.
The following sections describe each interface.

## Minimal Direct Control Interface

The PCT is required to support at least one 5 terminal connector for
basic HVAC and heat pump systems. The terminal numbering and definitions
for this connector is shown in Table 2-1. The terminal designations are
from NEMA DC 3-2003[^3].

**Table 2-1: Terminal Block 1 - Basic Thermostat Terminal Mapping
(Required)**

+-----+-----------------------+-------+-------------------------------+
| **T | **Signal Name**       | **N   | **Notes**                     |
| erm |                       | ormal |                               |
| \   |                       | Co    |                               |
| #** |                       | lor** |                               |
+=====+=======================+=======+===============================+
| 1   | (Conventional) Y:     | Y     | Conventional - First stage    |
|     | Cooling               | ellow | cooling                       |
|     |                       |       |                               |
|     |                       |       | Heat Pump - First stage       |
|     |                       |       | compressor. Will heat and     |
|     |                       |       | cool based on the output of   |
|     |                       |       | terminal 2 - O/B              |
+-----+-----------------------+-------+-------------------------------+
|     | (Heat Pump) Y:        |       |                               |
|     | Compressor            |       |                               |
+-----+-----------------------+-------+-------------------------------+
| 2   | (Conventional) W:     | White | Conventional - First stage    |
|     | Heating               |       | heating                       |
|     |                       |       |                               |
|     |                       |       | Heat Pump -- Configurable     |
|     |                       |       | option to energize the        |
|     |                       |       | terminal for cooling (O       |
|     |                       |       | option) or heating (B option) |
+-----+-----------------------+-------+-------------------------------+
|     | (Heat Pump) O/B:      |       |                               |
|     | Compressor            |       |                               |
+-----+-----------------------+-------+-------------------------------+
| 3   | G: Fan                | Green | Fan switch on thermostat or   |
|     |                       |       | on a call for cooling or heat |
|     |                       |       | pump                          |
+-----+-----------------------+-------+-------------------------------+
| 4   | C: 24 Vac Common      | Black | 24Vac transformer neutral     |
+-----+-----------------------+-------+-------------------------------+
| 5   | R: 24 Vac Power       | Red   | 24Vac transformer power. In a |
|     |                       |       | two source transformer        |
|     |                       |       | installation, this terminal   |
|     |                       |       | becomes Rh.                   |
+-----+-----------------------+-------+-------------------------------+
| 6   | Rc: 24 Vac Power      | Red   | OPTIONAL. Cooling transformer |
| (o  |                       |       | power for two source          |
| pt) |                       |       | transformer installations.    |
|     |                       |       | This terminal can be tied to  |
|     |                       |       | terminal #2 in single         |
|     |                       |       | transformer installations.    |
+-----+-----------------------+-------+-------------------------------+

## Advanced Thermostat Direct Control Interface

Thermostats designed to support advanced HVAC systems such as
multi-stage configurations will support a second terminal block. The
terminal numbering and definitions for this connector are shown in Table
2-2. Note that the terminal numbering starts with 7 to minimize
confusion with the mandatory terminal block. This will also facilitate
use of a single, standardized connector in the future.

**Table 2-2: Terminal Block 2 - Advanced Thermostat Terminal Mapping
(Optional)**

+------+----------------------+-------+-------------------------------+
| **   | **Signal Name**      | **N   | **Notes**                     |
| Term |                      | ormal |                               |
| \#** |                      | Co    |                               |
|      |                      | lor** |                               |
+======+======================+=======+===============================+
| 7    | (Conventional) W2:   | Va    | Conventional - Second stage   |
|      | Second Stage Heating | rious | heating                       |
|      |                      |       |                               |
|      |                      |       | Heat Pump -- Auxiliary and    |
|      |                      |       | emergency heating control     |
|      |                      |       | relay.                        |
+------+----------------------+-------+-------------------------------+
|      | (Heat Pump) Aux/E:   |       |                               |
|      | Auxiliary Heating    |       |                               |
+------+----------------------+-------+-------------------------------+
| 8    | Y2: Second Stage     | Blue  |  Second stage cooling for     |
|      | Cooling              | or    | both Conventional and Heat    |
|      |                      | O     | Pump configurations           |
|      |                      | range |                               |
+------+----------------------+-------+-------------------------------+
| 9    | L: Equipment Fault   | Va    | Installed as an input based   |
|      |                      | rious | 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.           |
+------+----------------------+-------+-------------------------------+
| 10   | (Conventional) W3:   | Va    | Conventional - Third stage    |
|      | Third Stage Heating  | rious | heating                       |
|      |                      |       |                               |
|      |                      |       | Heat Pump -- Second stage     |
|      |                      |       | auxiliary heating             |
+------+----------------------+-------+-------------------------------+
|      | (Heat Pump) Aux2:    |       |                               |
|      | Second Stage         |       |                               |
|      | Auxiliary Heating    |       |                               |
+------+----------------------+-------+-------------------------------+

Note that the optional connector may be extended in a vendor-dependent
manner to support additional functionality. These terminals should use
industry standardized designations, if appropriate, from those defined
in Table 2-3 below.

**Table 2-3 -- Terminal Markings for Low-Voltage Class 2 ControlsError:
Reference source not found**

![](media/image1.png){width="5.583333333333333in" height="5.9375in"}

## Digital Control Interface 

This interface definition is preliminary and advisory only. It is
anticipated that it will be defined in more detail in future revisions
of this document. This interface supports 48 VDC power and balanced,
full duplex serial transmission. The precise uses of these serial lines
are PCT vendor specific at this time. Vendors should consider using IEEE
802.3af Power over Ethernet standard in Mode B. An example of this
configuration is shown in Table 2-4.

**Table 2-4 -- Power over Ethernet Interface**

  ------------------------------------------------------------------------
  **RJ45 Pin \#**      **Wire Color\        **Signal**      **PoE**
                       (T568A)**                            
  -------------------- -------------------- --------------- --------------
  1                    White/Green          Transmit+       Mode A +

  2                    Green                Transmit-       Mode A +

  3                    White/Orange         Receive+        Mode A -

  4                    Blue                 Unused          Mode B +

  5                    White/Blue           Unused          Mode B +

  6                    Orange               Receive-        Mode A -

  7                    White/Brown          Unused          Mode B -

  8                    Brown                Unused          Mode B -
  ------------------------------------------------------------------------

# Expansion Interface

The expansion interface shall be available to extend the communication
capabilities of the thermostat as well as to provide an external means
of memory storage / logging. The physical interface (Figure 1) shall be
implemented by using the Multi-Media Card (MMC) format as defined in the
MMC System Specification Version 3.31[^4]. The logical interface shall
utilize the Serial Peripheral Interface (SPI) standard as defined in the
MMC System Specification version 3.31). The MMC System Specification
indicates that the SPI is optional for MMC devices, but it will be
mandatory for the PCT Expansion Interface. PCT manufacturers may
optionally support other physical and logical interfaces that provide
backwards compatibility with the MMC version 3.31. Examples are MMC
version 4.1 and SDIO version 1.1.

![](media/image2.png){width="6.498611111111111in"
height="1.8284722222222223in"}

Figure 1 MMC Interface and Card Examples

The interface shall be capable of recognizing whether a communications
network interface MMC card or a memory card has been placed in the
Expansion Interface. It shall also be able to identify which type of
communications interface is installed.

If a communications MMC card has been inserted and found to be valid and
operational by the PCT, this interface shall be used in lieu of the
internal, default, one-way communications capability in the PCT itself.
Regardless of whether communications takes place over an internal or
external interface, the communications shall take place in accordance
with the specifications set forth in section *4.* *Communications
Interface.*

**Table 3-1 -- MMC Pin assignment for SPI ModeError: Reference source
not found**

![](media/image3.png){width="0.4270833333333333in"
height="2.2916666666666665in"}![](media/image4.png){width="3.1041666666666665in"
height="2.2916666666666665in"}

# Communications Interface

The overall architecture of the PCT is designed to be compatible with
the architecture defined in the CEC demand response reference design
mentioned earlier. The architectural framework for this Demand
Responsive Infrastructure (DRI) is depicted in the CEC report using the
figure replicated here as Figure 2.

![](media/image5.wmf){width="3.402083333333333in"
height="2.5256944444444445in"}

Figure 2 DRI Function Services Framework

The architecture separates the physical infrastructure (e.g. a wireless
network) from the applications (e.g. the logical information model of
the PCT and the functions it performs) via a service model.

The physical communications interface is has two components -- a
mandatory, internal interface supporting a widely available wireless
communications technology such as the US Radio Broadcast Data System
(RBDS) standard[^5]; or an optional one- or two-way communications
interface connected through the Expansion Interface as selected and
specified by a load serving entity.

## Logical Information and Transaction Model

This section defines the logical attributes and transactions that are
necessary to represent and alter the internal state of the PCT. This
model determines how the PCT behaves when attributes are read or
updated, describes the meaning of those attributes, and specifies the
sequences of events (transactions) necessary to support the desired
functionality. The model is capable of exposing all of the attributes
and functionality that can be achieved through direct interaction with
the PCT's local human interface. The essential human interface
requirements are described by the Virtual Operation Model (VOM) in
Section 1.2.

This section will represent the static portion of the information model
(i.e. its attributes) using the Extensible Markup Language (XML). The
semantics of this model are derived from numerous existing standards and
industry agreements in an effort to be as consistent and compatible with
existing technology and implementations as possible. Note that for all
communications interface implementation profiles other than the
mandatory RBDS system, the XML representation of the model is a logical
representation only (i.e. it only defines the information exchanges; not
the actual form of the exchange itself).

The transaction aspects of the information model are represented by UML
activity diagrams to illustrate the transaction sequence that must occur
to carry out specific functions of the PCT.

## PCT Functions

This section enumerates the minimum functions to be carried out by the
PCT.

Programmability -- The PCT shall support at least a weekday and weekend
schedule (5-2 schedule) and each schedule shall have at least four
programmable periods (typically morning, day, evening, and night). The
schedules and time periods shall be independent for heating and cooling
modes of operation unless the PCT is operating in a dual operation mode.

Communications -- The PCT shall support messages from Section 4.3.3 to
enable CEC Title 24 compliance using one-way communications.

## PCT Messages and Attributes

This section describes the messages and associated data payloads
necessary to implement the functionality of the PCT as described in CEC
Title 24 PCT specifications (revision 29f) while being upwardly
compatible with the joint IOU PCT business requirements (revision 7).

Each of the documents describes different sets of messages. The CEC
Title 24 PCT specification is used as the base document for the purposes
of describing the minimum functionality of a one-way DR system. The
functionality described in the Joint IOU PCT document extends the Title
24 requirements to include usability features which can increase the
response to calls for short-term energy conservation. Proposed messages
necessary to support additional functionality are included as an
informative annex to this document.

If a message is received and validated, but it conflicts with a prior
message, the newer message is executed and any continuing action for the
prior message is automatically terminated by the PCT.

### Event Modes

The PCT specifications recognize the following two basic system event
modes:

-   Price Events, which can be overridden by the customer

-   Emergency Events, which may force an involuntary reduction in load.

In order to facilitate future changes in tariffs and regulations, the
messages and data payloads that support these events have been designed
to provide sufficient flexibility and information to handle such
changes. To provide this flexibility, while ensuring consistency,
several *common data classes* are defined below. These data classes are
used by most messages for addressing, event identification, and time
stamping. Event ID's are particularly important, because they are used
to cancel events and to allow multiple event transmissions for
message-transport reliability purposes. The addressing scheme may be
used to enable regional or even PCT-level control resolution.

#### Price Events

Initially, it is foreseen that a utility will wish to send a signal that
indicates that a super peak rate period is in effect. The utility may
wish to simply send a message that a peak price is in effect or send an
explicit price. The price event message defined below specifies a start
and stop time for which the price event is in effect as well as the
price itself. If the price field is set to zero, then this is a generic
super-peak event with no specific price. The customer's PCT will have a
default response to receiving a price event, but the owner may override
that programming. PCT vendors are free to provide whatever flexibility
they desire in allowing the owner to respond to the event alone or to
the event and price.

#### Emergency (Grid Reliability) Events

This event class allows the utility to issue specific directives to the
PCT in order to address a grid reliability situation. These events
provide a start and stop time as does a price event which allows them to
be scheduled in advance. There are two flavors of the basic reliability
event -- change temperature and set temperature. Basically this allows
the utility to specify an arbitrary temperature increase or decrease
from the PCT's current setpoint or simply specify a specific set point.
The ability to specify an explicit setpoint is required by Title 24 to
avoid the situation where customers change the setpoint just prior to
the start of a reliability event in order to "game" the system.

### Common Data Classes

All of the defined messages below make use of one or more common data
classes. These common classes (types) are used to represent addressing
information, date time stamps, and other common information.

#### Addressing \<ADDR\>

  ---------------------------------------------------------------------------------
  **Common                                                                
  Addressing                                                              
  Information                                                             
  \<ADDR\>**                                                              
  ------------- --------- ----------------------------------------------- ---------
  **Attribute   **Attr.   **Explanation**                                 **M/O**
  Name**        Type**                                                    

  **Data**                                                                

  Source        INT8U     Identifies the utility / DisCo that controls    M
  Utility                 the PCT (Ex: 5=SCE)                             

  DR Program    INT8U     Demand response program identifier (Ex: 3=CPP,  M
                          1=non-curtailable)                              

  Area / Sub    INT16U    Locates customer\                               M
  Ident                   (Ex:0=ALL, 1..999 identifies an 'area', 1000 up 
                          identifies a substation)                        

  Feeder        INT8U     Feeder number within a substation (0 = all      M
  Identifier              feeders, 1..N = feeder)                         

  Billing Point INT64U    Identifies individual customer                  O
  Ident                                                                   
  ---------------------------------------------------------------------------------

**Note:** This addressing scheme may be updated to coordinate with IPV6
terminology and be suitable for use as a subset of a valid IPV6 address.

#### Date/Time Stamp \<DTIME\>

  ----------------------------------------------------------------------------------
  **Common                                                                 
  Date/Time                                                                
  Information                                                              
  \<DTIME\>**                                                              
  -------------- --------- ----------------------------------------------- ---------
  **Attribute    **Attr.   **Explanation**                                 **M/O**
  Name**         Type**                                                    

  **Data**                                                                 

  NTP_Seconds    INT32U    Seconds since 0h January 1, 1900 UTC            M

  NTP_Fraction   INT32U    Fractional seconds                              O
  ----------------------------------------------------------------------------------

**Note:** All time stamps are in Universal Coordinated Time (UTC) using
the SNTP Version 4 format as defined in RFC 4330. SNTP uses the NTP
timestamp format which is represented as a 64-bit unsigned fixed-point
number, in seconds relative to 0h on 1 January 1900. The integer part is
in the first 32 bits and the fractional part in the last 32 bits. In the
fractional part, all bits should be set to 0.

#### Message Identification \<MSG_ID\>

  ---------------------------------------------------------------------------------
  **Common                                                                
  Event                                                                   
  Identifier                                                              
  \<EV_ID\>**                                                             
  ------------- --------- ----------------------------------------------- ---------
  **Attribute   **Attr.   **Explanation**                                 **M/O**
  Name**        Type**                                                    

  **Data**                                                                

  Message_ID    INT16U    Used to uniquely identify each message and      M
                          prevent replay.                                 
  ---------------------------------------------------------------------------------

#### Event Identification \<EV_ID\>

  ---------------------------------------------------------------------------------
  **Common                                                                
  Event                                                                   
  Identifier                                                              
  \<EV_ID\>**                                                             
  ------------- --------- ----------------------------------------------- ---------
  **Attribute   **Attr.   **Explanation**                                 **M/O**
  Name**        Type**                                                    

  **Data**                                                                

  Event_ID      INT16U    Used to provide a single, unique event          M
                          identifier for all messages associated with the 
                          same event. Cancellation events will reference  
                          this ID.                                        
  ---------------------------------------------------------------------------------

#### Event Price \<PRICE\>

  ---------------------------------------------------------------------------------------
  **Common Event                                                                
  Identifier                                                                    
  \<EV_ID\>**                                                                   
  ------------------- --------- ----------------------------------------------- ---------
  **Attribute Name**  **Attr.   **Explanation**                                 **M/O**
                      Type**                                                    

  **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  M123
                                (i.e. 200 means 2x price)                       

  Event_Price_Tier    INT8U     Indicator of relative price (ex:1=normal,       M123
                                2=high, 3=very high, \>1000 is a Tier ID)       
  ---------------------------------------------------------------------------------------

**Note:** One of the three M123 elements is mandatory

#### Cryptographic Hash Value \<CRYPTO\>

  ----------------------------------------------------------------------------------
  **Common                                                                 
  Crypto Hash                                                              
  Value                                                                    
  \<CRYPTO\>**                                                             
  -------------- --------- ----------------------------------------------- ---------
  **Attribute    **Attr.   **Explanation**                                 **M/O**
  Name**         Type**                                                    

  **Data**                                                                 

  Function ID    INT8U     1=SHA-1 (FIPS 180-2), 2=SHA-224, 3=SHA-256,     M
                           4=SHA-384, 5=SHA-512                            

  Hash_Value     INT512U   160 bits for SHA-1 hash value, etc.             M
  ----------------------------------------------------------------------------------

**Note:** The use of the cryptographic hash is optional in all messages
in this reference design but may be made mandatory in the future.

### Message Commands for Minimum Title 24 PCT Functionality 

#### Clock Set Command

  ------------------------------------------------------------------------------------
  **Clock Set                                                                
  Command**                                                                  
  ------------- ------------ ----------------------------------------------- ---------
  **Attribute   **Attr.      **Explanation**                                 **M/O**
  Name**        Type**                                                       

  **Data**                                                                   

  Message_ID    \<MSG_ID\>   Sequential ID for this message                  M

  Command Code  INT8U        Clock set command (ex: 1)                       M

  Address       \<ADDR\>     Which PCTs should use this information (this    M
                             may be ignored)                                 

  Now           \<DTIME\>    Present time (Universal Coordinated Time --     M
                             UTC)                                            

  DST_Next      \<DTIME\>    Time of next DST/SummerTime shift (ex:2006 302  M
                             7200)                                           

  DST_Offset    INT8S        Number of minutes (ex: -60 for USA change away  M
                             from DST)                                       

  Crypto        \<CRYPTO\>   Message integrity value                         O
  ------------------------------------------------------------------------------------

#### Price Event Command

  ---------------------------------------------------------------------------------------
  **Price Event                                                                 
  Notification**                                                                
  ---------------- ------------ ----------------------------------------------- ---------
  **Attribute      **Attr.      **Explanation**                                 **M/O**
  Name**           Type**                                                       

  **Data**                                                                      

  Message_ID       \<MSG_ID\>   Sequential ID for this message                  M

  Command Code     INT8U        (ex: 2)                                         M

  Address          \<ADDR\>     Which PCTs should use this information (this    M
                                may be ignored)                                 

  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        M
                                cancellation)                                   

  Event_Price      \<PRICE\>    One of three possible price options -- see      M
                                \<PRICE\>                                       

  Crypto           \<CRYPTO\>   Message integrity value                         O
  ---------------------------------------------------------------------------------------

#### Price Schedule Command

  ------------------------------------------------------------------------------------------
  **Price Schedule                                                                 
  Command**                                                                        
  ------------------- ------------ ----------------------------------------------- ---------
  **Attribute Name**  **Attr.      **Explanation**                                 **M/O**
                      Type**                                                       

  **Data**                                                                         

  Message_ID          \<MSG_ID\>   Sequential ID for this message                  M

  Command Code        INT8U        (ex: 23)                                        M

  Address             \<ADDR\>     Which PCTs should use this information (this    M
                                   may be ignored)                                 

  Number_of_Prices    INT8U        number of triple entries                        M

  1^st^\_Price        \<PRICE\>    One of three possible price options -- see      M
                                   \<PRICE\>                                       

  1^st^\_Start_Time   \<DTIME\>    Time that this price become effective           M

  1^st^\_End_Time     \<DTIME\>    Time that this price is no longer effective     M

  2^nd^\_Price        \<PRICE\>                                                    O

  2^nd^\_Start_Time   \<DTIME\>                                                    O

  2^nd^\_End_Time     \<DTIME\>                                                    O

  ....                                                                             O

  Crypto              \<CRYPTO\>   Message integrity value                         O
  ------------------------------------------------------------------------------------------

#### Change Temperature Command

  ------------------------------------------------------------------------------------
  **Change                                                                   
  Temperature                                                                
  Command**                                                                  
  ------------- ------------ ----------------------------------------------- ---------
  **Attribute   **Attr.      **Explanation**                                 **M/O**
  Name**        Type**                                                       

  **Data**                                                                   

  Message_ID    \<MSG_ID\>   Sequential ID for this message                  M

  Command Code  INT8U        (ex: 5)                                         M

  Address       \<ADDR\>     Which PCTs should use this information (this    M
                             may be ignored)                                 

  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        M
                             cancellation)                                   

  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. Some
PCTs receiving the message may be in heating mode while others are in
cooling mode, particularly where the PCTs reside in different
microclimates.

#### Set Temperature Command

  ----------------------------------------------------------------------------------------
  **Set Temperature                                                              
  Command**                                                                      
  ----------------- ------------ ----------------------------------------------- ---------
  **Attribute       **Attr.      **Explanation**                                 **M/O**
  Name**            Type**                                                       

  **Data**                                                                       

  Message_ID        \<MSG_ID\>   Sequential ID for this message                  M

  Command Code      INT8U        (ex: 6)                                         M

  Address           \<ADDR\>     Which PCTs should use this information (this    M
                                 may be ignored)                                 

  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        M
                                 cancellation)                                   

  New_Temperature   INT16U       New temperature setpoint, in tenths of a degree M
                                 Celsius                                         

  Crypto            \<CRYPTO\>   Message integrity value                         O
  ----------------------------------------------------------------------------------------

#### Display Message Command

  -------------------------------------------------------------------------------------
  **Display                                                                   
  Message                                                                     
  Command**                                                                   
  ------------- ------------- ----------------------------------------------- ---------
  **Attribute   **Attr.       **Explanation**                                 **M/O**
  Name**        Type**                                                        

  **Data**                                                                    

  Message_ID    \<MSG_ID\>    Sequential ID for this message                  M

  Command Code  INT8U         (ex: 7)                                         M

  Address       \<ADDR\>      Which PCTs should use this information (this    M
                              may be ignored)                                 

  Message       INT8U         Number of characters in message                 M
  Length                                                                      

  Message       STRING\[n\]   Message to display on display                   M

  Crypto        \<CRYPTO\>    Message integrity value                         O
  -------------------------------------------------------------------------------------

#### Cancel Event

  ------------------------------------------------------------------------------------
  **Cancel                                                                   
  Event**                                                                    
  ------------- ------------ ----------------------------------------------- ---------
  **Attribute   **Attr.      **Explanation**                                 **M/O**
  Name**        Type**                                                       

  **Data**                                                                   

  Message_ID    \<MSG_ID\>   Sequential ID for this message                  M

  Command Code  INT8U        (ex: 9)                                         M

  Address       \<ADDR\>     Which PCTs should use this information (this    M
                             may be ignored)                                 

  Event_ID      \<EV_ID\>    Identifier of this price event (used for        O
                             cancellation)                                   

  Crypto        \<CRYPTO\>   Message integrity value                         O
  ------------------------------------------------------------------------------------

#### Keep Alive

  -------------------------------------------------------------------------------------
  **Keep-alive                                                                
  Command**                                                                   
  -------------- ------------ ----------------------------------------------- ---------
  **Attribute    **Attr.      **Explanation**                                 **M/O**
  Name**         Type**                                                       

  **Data**                                                                    

  Message_ID     \<MSG_ID\>   Sequential ID for this message                  M

  Command Code   INT8U        (ex: 21)                                        M

  Address        \<ADDR\>     Which PCTs should use this information (this    M
                              may be ignored)                                 

  Crypto         \<CRYPTO\>   Message integrity value                         O
  -------------------------------------------------------------------------------------

## PCT Transactions

This section describes the transaction sequence necessary to implement
the PCT functions defined in section 4.2 using the attributes defined in
section 4.3.

![](media/image6.jpeg){width="3.9895833333333335in"
height="3.3333333333333335in"}

Figure 3 One-Way Critical Peak Price Event

![](media/image7.jpeg){width="5.239583333333333in"
height="4.864583333333333in"}

Figure 4 One-Way Emergency Events

## Implementation Profiles

An implementation profile for a communications interface describes how
the logical information models and transactions necessary to support it
are actually implemented using a specific standard via the enabling
services layer. The logical information models specify the attributes
that can be read and written from the PCT and their expected behavior
when transactions occur. The implementation profiles define the details
of how the underlying protocol is used to implement the model, services,
and transaction model. This reference design does not specify a
particular implementation profile -- this is described in a separate CEC
publication.

## Security

The PCT system will be a large and valuable asset to the state of
California. In order to ensure the system is able to perform in the
intended manner for the long term, protective measures must be
engineered into the solution from the beginning. A defense-in-depth
strategy leveraging risk management techniques is described herein,
including recommendations regarding the appropriate deployment of
security mechanisms at all levels to maximize effectiveness.

### Fundamental, Strategic Objectives

The PCT system must be designed to resist attacks, prove resilient in
the face of attack, and allow for expedient and effective recovery from
attack.

1.  **Resistance**

> Security measures must provide the system with a robust means to
> resist attacks. The foremost priority in this regard is to protect the
> ability to access and control the operation of PCT devices. Loss of
> access and control poses a huge risk to operational integrity and
> further risk of incurring large remedial costs.

2.  **Resilience**

> Security measures must provide the system with a means to withstand
> and respond to attacks. The foremost priority in this regard is to
> limit damage and loss if PCT access or control is compromised.
> Minimizing damage and loss is of benefit to system effectiveness as
> well as public safety.

3.  **Recovery**

> Security measures must provide the system with a means to recover from
> attack. The foremost priority in this regard is the recovery of PCT
> access or control in the event of compromise. The ability to quickly
> regain confidence in the safe and reliable operation of the system as
> intended is of paramount importance.

### Assumptions

The following constraints are assumed in considering security solutions
for the PCT system:

1.  **Human Factors**

> Although sophisticated technology can be applied to realize security
> objectives, the largest security risks are posed by inadequate or
> compromised security procedures within the responsible human
> organizations. Accountability and safeguards are essential at every
> level of the human security structure to avoid compromising critical
> system information (e.g. cryptographic keys). Organizational lapses
> can result from carelessness, negligence, complacency, poor judgment,
> poor human communication, inexperience, ignorance, collusion, and
> revenge, not to mention bribery, blackmail, and coercion.

2.  **Practical Recovery**

> Security measures must be built into the PCTs and the head-end system
> from the beginning, anticipating different kinds of loss and
> appropriate system responses. Viable approaches cannot include travel
> to customer sites. Should recovery prove impossible for even a
> moderate number of PCTs (say 1,000), the replacement/repair costs and
> negative publicity are likely to be prohibitive.

3.  **Security Priorities**

> Of the four major communication security issues - availability,
> integrity/authenticity, confidentiality, and non-repudiation - the PCT
> system needs to focus first on authentication of message senders and
> second on the integrity of the message. For the one-way (broadcast)
> system, availability is a lower priority since lost messages can be
> repeated, and confidentiality is not a priority at all. While
> cryptographic measures may be used in support of authentication
> mechanisms, encryption is not necessary for confidentiality purposes.
> Non-repudiation may need to be addressed to the extent of preventing
> customers from simply claiming their equipment was malfunctioning
> during an event.

4.  **Distribution Channels**

> PCTs may be distributed through manufacturer, utility, or retail
> channels. Each approach can pose distinct advantages and drawbacks,
> spanning a range of security considerations.
>
> The first impact of this range of distribution mechanisms is that the
> installation process for the PCTs must be kept as simple as possible.
> Manufacturing workers, home contractors, and customers cannot be
> expected to have security expertise. Nor can they be reasonably
> expected to read a manual for this product.
>
> The second issue is that cryptographic materials associated with
> individual PCTs or groups of PCTs must be handled in a procedural
> manner. The process must protect critical, complementary pieces of
> cryptographic material from ever being exposed to the same person or
> stored in a common location.
>
> To the extent possible, PCTs should be manufactured and distributed as
> part of multiple groups that have unique security credentials. This
> approach will lessen the risk associated with any single point of
> compromise.

5.  **Feedback**

> Even when using one-way communications, utilities may benefit from PCT
> feedback when malfunctions or potential threats arise. PCT
> manufacturers can be encouraged to employ software techniques that
> recognize certain kinds of communications attacks. These in turn can
> invoke defensive measures to ignore questionable commands or prompt
> customers to report associated error codes through an automated phone
> system. The information reported from an incident might include the
> following, although a lot of this information could be captured during
> the PCT registration process at time of installation:

-   PCT model number

-   PCT serial number

-   Customer's name

-   Customer's zip code

-   Customer's phone number

-   Error code

-   Date and time of occurrence (tagged by the PCT)

### Risk Management Approach

Security for the PCT system should be evaluated using a risk management
approach. Such an approach includes:

-   Delineating **assets** to be protected, including their relative
    value and their sensitivity to attack.

-   Identifying **threats**, including their possible source, intent and
    strength.

-   Enumerating **vulnerabilities**, including their possible frequency
    and serverity.

-   Mapping specific threats through vulnerabilities to assets

-   Determining appropriate mitigation techniques

The following sections illustrate how this approach was followed.

### Possible Attacks

To determine the assets, threats and vulnerabilities of the PCT system,
the task force considered several scenarios. These scenarios fall into
several categories depending on the communications layer affected:

The task force has identified the following scenarios for possible
application layer attacks:

1.  Attacker turns on all air-conditioning units, causing a sudden,
    excessive, unexpected load, possibly leading to blackouts or grid
    instability.

2.  Attacker recalls an authentic emergency signal, preventing the
    required reduction in load and forcing utilities to take other
    measures such as blackouts or buying energy at higher costs.

3.  Attacker shuts down all air conditioning units, causing annoyance
    and possible health concerns among some customers. Would be of more
    concern in states with more severe weather conditions.

4.  Attacker downloads new software into the PCT or the PCT
    communications module. This attack will be nullified on the Title 24
    PCTs by simply not acting on these messages if they come over the
    broadcast network.

5.  Attacker sends false acknowledgements. Not an issue on the broadcast
    network.

6.  Attacker issues false time synchronization, potentially causing
    events to occur sooner or later than they normally would have.

7.  Attacker causes false messages to appear on the thermostat display,
    misleading customer and perhaps causing incorrect behavior that
    could affect load or cause overload of utility customer service,
    e.g. "Please call utility now."

8.  A customer decreases the air conditioner setpoint prior to an
    expected event, or changes the time locally, causing air
    conditioning to run normally during the event.

The task force has identified the following scenarios for possible
network or transport layer attacks:

1.  Attacker takes control of head-end radio system through the
    initiating organization's internal network or its interfaces with
    third parties.

2.  Attacker causes denial of service by flooding the head-end IP
    network with acknowledgements (from the two-way IOU networks) or
    other valid messages.

3.  Attacker intercepts wireless messages.

The task force has identified the following physical layer attacks:

1.  Attacker jams or sends false messages from a ground station or
    vehicle, affecting a limited number of thermostats

2.  Attacker jams or sends false messages from a balloon or other
    aircraft, increasing range of the attack.

3.  Customer disables thermostat antenna.

Figure 5 summarizes the goals, threats, type of attack, and mechanism
for each of these scenarios. In doing so, it maps the threats through
vulnerabilities to the system assets as discussed above.

![](media/image8.png){width="5.996527777777778in"
height="3.7395833333333335in"}

Figure 5 -- Summary of Possible Attacks on the PCT System

### Non-Cryptographic Mitigation Methods

The task force determined that these threats were most effectively
addressed through a comprehensive defense-in-depth approach, as
illustrated in Figure 6.

Most modern information systems tend to focus on the use of cryptography
as the primary defense against attacks. However, cryptography is only
one possible mitigation technique. The unique design, characteristics,
and constraints of the PCT system provide opportunity to leverage
several non-cryptographic techniques. The principles involved in these
techniques include:

-   Using time as an ally, slowing the capability of an intruder to use
    PCT resources

-   Limiting the allowable behavior of the PCT to prevent it from
    performing actions that, while theoretically possible, would never
    be used for beneficial purposes in actual practice.

-   Relying on detection as well as prevention mechanisms as deterrents.

![](media/image9.wmf)

Figure 6 -- Mitigation Measures for the PCT System showing
Defense-in-Depth

#### Business Logic

1.  Thermostats shall not accept remote commands to increase energy
    usage except the cancel event message, discussed below.

2.  Thermostats shall have hard-coded limits on what setpoints will be
    accepted via remote commands, to prevent unsafe setpoints.

3.  Thermostats shall randomly delay for up to 30 minutes after being
    instructed to normally end or cancel an energy reduction event,
    avoiding sudden increases in load on the grid. The display of the
    thermostat shall not indicate the end of the event until after the
    random delay.

4.  Thermostats will never automatically increase energy usage at the
    end of an event by any more than they originally reduced it.

5.  Time synchronization commands received via the remote network shall
    override any time set locally.

#### Detection and Environment

The working group has no authority over the transmission end of the
network, but can only define a reference design for the thermostats
themselves. However, it has identified the following recommended
security measures for the network as a whole, plus two detection
requirements for the PCTs:

1.  Create an intrusion detection system for the broadcast network. Such
    a system might consist of receivers spaced over the service
    territory that can compare the received broadcast messages with what
    was actually transmitted, and thus identify a false transmitter.

2.  Change the thermostat time frequently enough to reduce the
    effectiveness of time change attacks.

3.  Use historical energy usage data from the metering system to detect
    when a customer has disabled the thermostat's antenna or is
    attempting to "game" the system.

4.  If private cryptographic material (e.g. a secret key) is stored for
    long periods of time in the thermostat, the thermostat must provide
    a tamper detection mechanism, e.g. per FIPS 140-2 standards. This
    requirement would not apply if public keys are used since this
    information can be made freely available.

5.  Thermostats must include a non-modifiable, timestamped log of
    received messages. An example of such a mechanism would be a
    non-volatile memory card inserted in the expansion slot.

### Message Content

Certain fields within the message may be handled in specific ways that
will augment the security of the overall solution. Two fields that are
particularly relevant are the timestamp and message identifier. The
timestamp is necessary to link the message to a specific point in time,
yet it can be easily accommodated (predicted) by an attacker wishing to
inject an unauthentic message. It is important that the message
identifier cannot also be predicted in a similar fashion. For this
reason the recommended solution does not employ sequential message
identifiers, but rather uses elements similar to the cryptographic
nonce.

A cryptographic nonce is a value used only once, and is frequently
either random or pseudo-random in nature. By comparing the identifier of
an incoming message to a list of previously received identifiers, the
PCT can easily detect if an impostor is attempting to re-use a message
at a later time. While the PCT may not be able to store the identifier
of every message it ever receives, it can easily store a significant
number and scan them for duplicates upon receipt of a new message. By
establishing a range of valid message identifiers that is only slightly
larger than the quantity stored in the PCT, one can ensure that it is
difficult for an attacker to guess an unused identifier. Thus, the
difference in the size of the valid identifier range and the PCT store
should be large enough to provide reasonable random or pseudo-random
selection, but no more, as the ratio of unused to recorded quantities is
directly reflected in the odds of an attacker guessing a valid (unused)
identifier.

Together, the timestamp and the message identifier reflect information
that will change from one message to another, regardless of message
instruction. By also removing predictable characteristics from the
message identifier, the recommended solution forms the basis for strong
resistance to replay attacks. This defense is complimented by use of a
MAC (message authentication code) or an HMAC (keyed-hash message
authentication code). These cryptographic techniques allow for easy
detection of message manipulation, and present the attacker with a
particular challenge in replicating the process to produce a plausible
message.

### Cryptographic Mitigation Approaches

The task force originally considered two primary categories of
cryptographic security solutions. The first option that the task force
considered focused around the use of asymmetric cryptography. While this
option was heavily favored among the cryptographic experts that the task
force consulted, the option also depended upon the up-front definition
of roles and responsibilities for all entities before key material could
be generated and distributed. The second option that the task force
considered utilized a "secret-sharing" approach (also sometimes referred
to as "key-splitting") with symmetric algorithms. This option alleviated
the manufacturing / key material / distribution dilemma, but was less
preferred from a cryptographic standpoint and not as efficient in
regards to long term key management.

Ultimately, the task force devised a third solution which combined
select features from each of the two previous options. In short, the
solution leverages the strength and key management advantages of the
asymmetric approach with the organizational and logistical flexibility
of secret-sharing.

(Note: It is assumed that authentication and integrity checking are
provided through a Message Authentication Code (MAC) included in each
message. Alternately, the entire message could be encrypted for the same
effect.)

#### Roles and Responsibilities

For the purposes of discussion the following terms shall be used to
refer to the various entities involved in communication sequences:

  --------------- -------------------------------------------------------
  System Owner    The entity responsible for oversight and control of the
                  entire PCT system. This represents the highest and
                  broadest level of authority. Any messages from the
                  System Owner to the PCT must go through the System
                  Operator.

  System Operator The entity responsible for operation and control of a
                  specific and defined geographic / service area. This
                  entity will be responsible for sending messages to the
                  PCT.

  Manufacturer    The entity responsible for production of the PCT. This
                  entity must have the capacity to build all required
                  cryptographic capability into the PCT.

  Installer       The entity responsible for placing the PCT in service
                  within the home. This entity may or may not have
                  technical training or expertise.

  PCT             The Programmable Communicating Thermostat in the home.
  --------------- -------------------------------------------------------

#### Concepts, Challenges, and Solution Approach

The general concept behind the recommended solution is to put a unique,
random number into each PCT at the time of manufacture. This number is
subsequently used in the installation process to register the PCT, as
well as facilitate the transmission of cryptographic key information to
the device. The recommended solution uses Elliptic Curve Cryptography
(ECC), which represents a recent and powerful generation of asymmetric
cryptographic algorithms.

Asymmetric algorithms utilize a set of mathematical formulas that are
relatively easy to calculate in one direction, but feasibly impractical
to calculate in reverse. This is manifested by the use of two keys that
are related, but not the same. Information encrypted by one key can only
be decrypted by the other key. In the scenario of authenticating
broadcast information, this allows the message to be encrypted or signed
using a single, closely guarded private key, and then decrypted or
verified using a freely available and copied public key. The private key
is at no practical risk of compromise from the public key due to the
one-way nature of the relationship between the two -- an attacker cannot
feasibly calculate the private key even if they have unfettered access
to the public key. By simply being able to decrypt the message with the
public key, the recipient verifies that the message must have come from
the holder of the corresponding private key.

![](media/image10.png){width="4.544444444444444in"
height="1.7284722222222222in"}

Figure 7 -- Asymmetric Cryptographic Key Relationship

The primary challenge in the case of the PCT is the distribution of key
material. Cryptographic keys are represented digitally by a very long
string of alphanumeric characters, and as such would be difficult to
manually enter into a PCT by any practical means. It would be relatively
easy for the manufacturer to embed key material in the device, however
in order to produce a public key one must also produce a corresponding
private key. This brings up the question of handling and storage of the
private key. Until the governing body defines exactly which entity shall
be responsible for which role in the system *and* these entities are
adequately prepared to handle cryptographic secrets, private keys may
simply not be produced. Thus, any practical solution must not depend
upon keys being produced before distribution and deployment of PCTs may
begin.

One particular cryptographic technique that may be employed to resolve
such a dilemma is "secret sharing." This model uses the concept of
dividing critical information up where no single entity possesses enough
information by itself to re-construct the secret. This can be applied to
the PCT by placing a large random number in each thermostat along with
an out-of-band communications channel for initialization / installation
/ activation. The out-of-band communications channel could be a phone
number or website where the *Installer* could achieve a sufficient level
of confidence regarding the identity of the activating entity (either
the *System Owner* or the *System Operator*).

#### PCT Registration Use Case

**[Primary Actor:]{.underline}** *Installer*

**[Goal:]{.underline}** Register a Programmable Communicating Thermostat
with the Title 24 One-Way Broadcast System.

**[Stakeholders and Interests:]{.underline}**

*Installer:* Wants confirmation of successful *PCT* registration with
minimal time and hassle.

*System Owner:* Wants to have primary and backup public keys installed
in the *PCT*.

*System Operator:* Wants to have public key installed in the *PCT*.
Wants to be able to place *PCT* in a specific operational group (e.g.:
region, substation, neighborhood, etc...).

**[Initial Conditions:]{.underline}**

-   The *PCT* is physically located inside a residence and has yet to be
    activated.

-   The *Manufacturer* has embedded a 160-bit random number in the
    *PCT*.

-   The *System Owner* has primary and backup public/private key pairs,
    and is known to the *System Operator*.

-   The *System Operator* has a public/private key pair, and is known to
    the *System Owner*.

-   The *Installer* has access to the out-of-band communications
    channel.

**[Minimal Guarantees:]{.underline}**

-   *PCT* remains capable of being registered on the system.

-   No private keys are compromised.

-   The *PCT* does not have increased vulnerability.

**[Success Guarantees:]{.underline}**

-   *PCT* is capable of receiving price or emergency signals.

-   *PCT* can determine signals are authentic.

-   *PCT* can be re-registered.

-   *System Owner* and *System Operator* may distribute new public keys
    to the *PCT*.

**[Trigger:]{.underline}** Homeowner summons *Installer* to residence
(or becomes *Installer*) for the purpose of installing a *PCT*.

**[Main Success Scenario:]{.underline}**

1.  *Installer* retrieves random number from *PCT*.

2.  *Installer* contacts *System Operator* via out-of-band channel.

3.  *Installer* relays *PCT* random number to *System Operator*.

4.  *System Operator* relays *PCT* random number to *System Owner*.

5.  *System Owner* performs two XOR operations:

-   With *PCT* random number and *System Owner's* primary public key

-   With *PCT* random number and *System Owner's* backup public key.

6.  *System Owner* sends results of XOR operations to *System Operator*.

7.  *System Operator* performs XOR operation with *PCT* random number
    and *System Operator's* public key.

8.  *System Operator* transmits registration signal including the
    labeled results of all three XOR operations to *PCT*.

9.  *PCT* performs XOR operation with its random number and each of the
    three result numbers received via registration signal, recovering
    three labeled public keys.

10. *System Owner* encrypts activation message with *System Owner's*
    primary public key.

11. *System Owner* sends (encrypted) activation message to *System
    Operator*.

12. *System Operator* encrypts activation message with *System
    Operator's* private key.

13. *System Operator* transmits (double encrypted) activation message to
    *PCT*.

14. *PCT* decrypts activation message: first with *System Operator's*
    public key; second with *System Owner's* primary public key.

15. *PCT* activates.

![](media/image11.png){width="5.992361111111111in"
height="7.832638888888889in"}

Figure 8 -- Installation Message Sequence

#### Key Management

In comparison to other technological environments, the use of keys in
the PCT system is very infrequent, and any direct monetary value is
quite low. Indirect value may be higher for certain malicious parties,
although this is debatable and may not be evaluated without some degree
of speculation and subjective assumptions. However, due diligence
dictates that a solution accommodate the possibility that keys may be
compromised at some point. Therefore, the solution described herein
provides a moderate degree of risk mitigation by utilizing a
three-tiered hierarchy of keys and minimizing the use (and exposure) of
keys with greater authority.

In this design, the *System Owner* would possess two separate
public/private key pairs -- one primary and one backup. The sole purpose
of the backup public key would be to distribute a new primary public key
in the event the original primary private key had been compromised. If
the primary private key is never compromised, then the backup private
key is never used and may be kept in a secure location for the duration
of the PCT program. The primary keys shall be used by the *System Owner*
to authenticate the public key of the *System Operator*, and to send
authenticated system-wide messages (i.e.: emergency event).

For any single PCT, the *System Operator* will also have a
public/private key pair. These keys shall be used for all PCT
communications, as the *System Operator* shall maintain control of the
physical communications link to the PCTs. Messages from the *System
Owner* (utilizing the *System Owner* key as well) would be passed
through the *System Operator*, and ideally would be kept to a minimum.
The *System Operator* keys shall actually be used alone for the vast
majority of PCT communications.

The *System Operator* may, however, posses any number of public/private
key pairs in total. While there would be only one *System Operator*
public key for a given PCT, the *System Operator* could maintain several
sets of public/private key pairs representing the different operating
regions, substations, or service territories, and assign a specific
public key to a PCT accordingly at the time of
registration/installation.

![](media/image12.png){width="5.169444444444444in"
height="3.5555555555555554in"}

Figure 9 -- Key Hierarchy

### Remaining Issues

An industry organization must be formed to complete this reference
design and to choose an appropriate security solution. The task force
has decided that the following steps still need to be resolved:

1.  Finalize the **appropriate algorithms** to use. While ECC is
    recommended for asymmetric algorithms, any necessary hashing or key
    wrapping algorithms are still to be determined.

2.  Finalize the **number of levels and groups of keys**. It is
    desirable that multiple groups be defined and distributed among the
    thermostats so that the compromise of any given key may have a
    limited impact.

3.  Determining **how often to change the time and/or send a heartbeat
    message**. These factors have an impact on installation.

###  {#section .unnumbered}

# Human-Machine Interface

This section discusses the interface between humans and the PCT.

## Terminology

The task force agreed that at this point in the development of the PCT
system, the only human-machine interface standardization required to
support the Title 24 requirements is a clear definition of terminology.
All other standard features of the PCT are up to the discretion and
innovative talents of the thermostat manufacturers. **NOTE:** Minimum
programming requirements shall meet the current Energy Star
specifications.

PCT user interface and documentation shall use the following
terminology.

+-----------------+----------------------------------------------------+
| **Reliability   | Refers to a Stage 1 Emergency or Stage 2 Emergency |
| Event /         | message from the utility. Upon receiving an        |
| Emergency       | emergency event, the PCT shall adjust its settings |
| Event**         | according to the Title 24 requirements.            |
+-----------------+----------------------------------------------------+
| **Price Event** | Refers to a change in pricing sent to the PCT from |
|                 | the utility.                                       |
+-----------------+----------------------------------------------------+
| **Stage 1       | The lowest level of the emergency events.          |
| Emergency**     |                                                    |
+-----------------+----------------------------------------------------+
| **Stage 2       | The highest level of the emergency events.         |
| Emergency**     |                                                    |
+-----------------+----------------------------------------------------+
| **Critical Peak | A type of price event. When a CPP is received by   |
| Pricing Event   | the PCT, the device should take appropriate        |
| (CPP)**         | behavior as defined by the settings configured by  |
|                 | the customer.                                      |
+-----------------+----------------------------------------------------+
| **Over-Ride**   | Refers to a person adjusting the functional        |
|                 | behavior of the PCT to ignore a State 1 emergency  |
|                 | message. Upon receiving a Stage 2 emergency        |
|                 | message, a PCT shall act normally and ignore the   |
|                 | Over-Ride setting.                                 |
+-----------------+----------------------------------------------------+
| **Provision**   | Describes the commissioning or binding process of  |
|                 | connecting a PCT to the wide area network or to an |
|                 | in-premise network.                                |
|                 |                                                    |
|                 | NOTE: This process depends critically on the data  |
|                 | security solution chosen, as described in section  |
|                 | 0.6.                                               |
+-----------------+----------------------------------------------------+
| **Pending       | Refers to a price event or emergency event that is |
| Event**         | scheduled but has not yet happened.                |
+-----------------+----------------------------------------------------+
| **Active        | Refers to a price event or emergency event that is |
| Event**         | underway.                                          |
+-----------------+----------------------------------------------------+

## Next Steps and Issues to be Resolved

An industry organization must be formed to complete this reference
design and to discuss further possibilities for user interface
standardization. This section discusses some of those issues.

### Interaction with "Hold" Functions

There is some concern how the Emergency Events interact with temperature
"hold" functions that may be implemented by some PCTs. A philosophy that
has been suggested is that after all events are complete, the PCT should
restore the state that existed prior to any of the events, including any
"hold" settings.

### Recovery from "Off" State within an Active Event

The system must consider the person who comes home from a vacation and
finds the home is at a high temperature because the system was OFF. The
person may find they are in a Stage 2 Emergency and *cannot* turn on any
cooling. It has been suggested that the PCT should permit cooling or
heating to take place during an emergency event up to the setpoints
associated with the event currently in progress.

### Standardization of Colors, Indicators, and Icons

Icons and symbols can provide a distinct advantage over text, because
they have the power to instantly convey an associated meaning and to
overcome language barriers. Overuse of symbols and color, however, can
create more confusion than clarity. Suppliers and users would benefit
greatly from adoption of common usage.

Typical uses of symbols and icons are event notification, pending event
notification, and state or status indicators. Some possible examples are
included in the following sections. None of these examples have yet been
agreed upon; the issues must be addressed by the proposed industry
organization.

#### Example Colors

The following suggestions have been made for standardized colors based
on common usage in user interface design:

-   BLUE symbols indicate COOL or decreasing temperature.

-   RED symbols indicate HEAT or increasing temperature.

-   YELLOW symbols indicate status.

-   GREEN represents power-on or operational status.

#### Example Indicators

The following suggestions have been made for standardized indicators:

-   The green indicator shows operational status for a PCT device. When
    running properly and ready to communicate with the utility company,
    this indicator will be ON, signaling that the PCT is healthy and
    ready to performs its designated functions. In this case it will
    indicate RF communication is active and the device is ready to
    receive or transmit (in two-way operation) data. Upon RESET (if
    equipped), this indicator should turn off, and then re-illuminate
    once the system has rebooted and is ready.

-   The amber or yellow indicator shows that the PCT is communicating
    with the utility company.

-   The blue indicator shows a pending or present price event. When
    flashing, it indicates that a pending price event will occur within
    the next 24hrs. When the indicator is solid, the price event is in
    progress.

-   The red indicator shows an emergency event. When flashing, it
    indicates that a Stage1 emergency event is in progress. When solid,
    it indicates that a Stage 2 emergency event is in progress.

#### Example Icons

The icons in Table 1 have been suggested as possibilities for
standardizing PCT icons.

Table 1 Examples of Possible Standard Icons

  ---------------------------------------------------------------------------------------
  **Function**                     **Example Icon**
  -------------------------------- ------------------------------------------------------
  OFF                              ![](media/image13.png)

  POWER                            ![](media/image14.png){width="0.3145833333333333in"
                                   height="0.38958333333333334in"}

  FAN                              ![](media/image15.png)

  COOL                             ![](media/image16.png)

  HEAT                             ![](media/image17.png)

  AUTO MODE                        ![](media/image18.png)

  BATTERY INDICATOR                ![](media/image19.wmf){width="0.4965277777777778in"
                                   height="0.2013888888888889in"}
                                   ![](media/image20.wmf){width="0.16944444444444445in"
                                   height="0.4222222222222222in"}

  UP                               ![](media/image21.png)![](media/image22.png)

  DOWN                             ![](media/image23.png)![](media/image24.png)

  LOCK                             ![](media/image25.png){width="0.22847222222222222in"
                                   height="0.3729166666666667in"}

  UNLOCK                           ![](media/image26.png){width="0.3347222222222222in"
                                   height="0.38958333333333334in"}

  CPP Indicator                    **\$**

  EMERGENCY STAGE 1 OR 2 INDICATOR **!**
  LABEL                            

  LIGHT                            ![](media/image27.png)
  ---------------------------------------------------------------------------------------

#### Example Displays

Error: Reference source not found and Error: Reference source not found
illustrate how standardized colors and icons could be used by PCT
suppliers to create distinctive displays. The examples in Error:
Reference source not found might be used by touch-screen models.

![](media/image28.wmf){width="3.5964566929133857in"
height="2.7901574803149605in"}![](media/image29.wmf){width="3.5in"
height="2.7763779527559054in"}

![](media/image30.wmf){width="3.6in"
height="2.572047244094488in"}![](media/image31.wmf){width="3.575196850393701in"
height="2.103543307086614in"}![](media/image32.wmf){width="3.575196850393701in"
height="2.104330708661417in"}

# Annex A: PCT Use Cases

**Scenario 1: Customer I**nstalls PCT

  ------- -----------------------------------------------------------------
  1       Installer installs PCT in a new home or a qualifying re-model.

  2       Installer connects any required devices (antenna, external
          communication module, etc.) to PCT to support one-way
          communications

  3       Installer puts PCT into Provisioning Mode to receive security and
          address information

  4       Installer calls phone number to initiate PCT security and address
          registration

  5       Installer provides the PCT's unique identifier number to
          automated system or phone service personnel

  6       Utility system transmits PCT specific data in a Provisioning
          Message over the Utility Communication Infrastructure which is
          only acted on by the PCT being installed

  7       PCT receives Provisioning Message and uses message data to
          complete configuration of security keys and address information

  8       PCT provides visual feedback to Installer that provisioning is
          successful

  \\      

  Notes   Installer can be home builder, contractor, customer or other.

          

          

          
  ------- -----------------------------------------------------------------

**Scenario 2: Customer p**rograms PCT

  ------- -----------------------------------------------------------------
  1       Customer can set the time on the PCT but the time should be
          changed upon receipt of a valid time signal from the Utility
          Communication Infrastructure

  2       Customer programs PCT for normal desired temperature for
          different times of day and for different days. (This is
          functionally identical to current programmable thermostats)

  3       Customer can optionally change the default PCT program on its
          response to Price Events and Stage 1 Emergency Events

  3.1     Customer can change the temperature offset for cooling upon
          receipt of a Price Event

  3.2     Customer can change the temperature offset for heating upon
          receipt of a Price Event

  3.3     Customer can change the price level response based on the signals
          that the customer\'s utility sends and the capabilities of the
          specific model of PCT

  3.4     Customer can change the temperature offset for cooling upon
          receipt of a Stage 1 Emergency Event

  3.5     Customer can change the temperature offset for heating upon
          receipt of a Stage 1 Emergency Event

  4       Customer pushes \"Run Program\" button to activate normal PCT
          schedule

  5       PCT sets temperature according to the day and time of the
          programmed schedule

  6       PCT adjusts time when it receives a Clock Set message from the
          Utility Communication Infrastructure

  Notes   
  ------- -----------------------------------------------------------------

**Scenario 3: PCT responds to 'Price Event' m**essage

  ------- -----------------------------------------------------------------
  1       Utility sends Price Event message

  1.1     Utility includes at least one form of pricing information in
          Price Event message (price / kW hour, price ratio, price tier)

  2       PCT receives Price Event message from the Utility Communication
          Infrastructure

  3       PCT responds to the Price Event message based on pricing
          information and the PCT\'s programmed response (Many options
          here. Assuming a basic response)

  4       PCT adjusts the thermostat setting equal to the programmed
          temperature offset setting for a Price Event

  5       PCT remains responsive to customer input to override the setback
          temperature setting

  6       PCT waits until the Event End Time as indicated by the Price
          Event message

  7       PCT returns to the operating state that existed prior to the
          Price Event message (Could be normal programmed schedule, holding
          a specific temperature, etc.)

  Notes   PCT will also respond to a Cancel Event message prior to the
          Event End Time
  ------- -----------------------------------------------------------------

**Scenario 4: PCT responds to 'Price Event' message** based on price

  ------- -----------------------------------------------------------------
  1       Utility sends Price Event message

  1.1     Utility includes at least one form of pricing information in
          Price Event message (price / kW hour, price ratio, price tier)

  2       PCT receives Price Event message from the Utility Communication
          Infrastructure

  3       PCT responds to the Price Event message based on pricing
          information and the PCT\'s programmed response

  4       PCT chooses not to respond to Price Event because the programmed
          response is to ignore events under a specific threshold price

  5       Utility measures response to Price Event and determines that it
          does not meet the Utility\'s needs

  6       Utility has to purchase additional power at higher prices to meet
          demand

  7       Utility sends new Price Event message with increased pricing
          level information

  8       PCT receives Price Event message from the Utility Communication
          Infrastructure

  9       PCT responds to Price Event message based on pricing information
          and the PCT\'s programmed response

  10      PCT now chooses to respond to Price Event message because the
          programmed response\'s threshold has been met

  11      PCT adjusts the thermostat setting equal to the programmed
          temperature offset setting for a Price Event

  12      PCT remains responsive to customer input to override the setback
          temperature setting

  13      PCT waits until the Event End Time as indicated by the Price
          Event message

  14      PCT returns to the operating state that existed prior to the
          Price Event message (Could be normal programmed schedule, holding
          a specific temperature, etc.)

  Notes   For a customer to realistically respond to different price levels
          received from the one way communication system, the customer will
          need to have an installed Time of Use meter

          PCT will also respond to a Cancel Event message prior to the
          Event End Time
  ------- -----------------------------------------------------------------

Scenario 5: PCT responds to Reliability Event message

  ------- -----------------------------------------------------------------
  1       Utility sends Reliability Event messages

  1.1     Utility sends Reliability Event - Change Temperature message that
          includes a temperature offset change value

  1.2     Utility sends Reliability Event - Set Temperature message that
          includes an absolute temperature set point value

  2       PCT receives Reliability Event message from the Utility
          Communication Infrastructure

  3       PCT responds to the Reliability Event message based on the PCT\'s
          programmed response

  4       PCT adjusts the thermostat setting to save the most energy based
          on the received Reliability Event messages (default response) or
          to the customer\'s programmed response for a Reliability Event

  5       PCT remains responsive to customer input to override the
          Reliability Event temperature setting

  6       PCT waits until the Event End Time as indicated by the
          Reliability Event message

  7       PCT returns to the operating state that existed prior to the
          Reliability Event message (Could be normal programmed schedule,
          holding a specific temperature, etc.)

  Notes   PCT will also respond to a Cancel Event message prior to the
          Event End Time

          With two temperature setting messages, the desired default
          response and acceptable programmable responses need to be well
          defined
  ------- -----------------------------------------------------------------

**Scenario 6: PCT does not respond to Reliability Event message**

  ----- -----------------------------------------------------------------
  1     Utility sends Reliability Event messages

  1.1   Utility sends Reliability Event - Change Temperature message that
        includes a temperature offset change value

  1.2   Utility sends Reliability Event - Set Temperature message that
        includes an absolute temperature set point value

  2     PCT receives Reliability Event message from the Utility
        Communication Infrastructure

  3     PCT responds to the Reliability Event message based on the PCT\'s
        programmed response

  4     PCT chooses not to respond to the Reliability Event because the
        programmed response is to ignore Reliability Events
  ----- -----------------------------------------------------------------

**Scenario 7: PCT responds to Emergency Event message**

  ------- -----------------------------------------------------------------
  1       Utility sends Emergency Event messages

  1.1     Utility sends Emergency Event - Change Temperature message that
          includes a temperature offset change value

  1.2     Utility sends Emergency Event - Set Temperature message that
          includes an absolute temperature set point value

  2       PCT receives Emergency Event message from the Utility
          Communication Infrastructure

  3       PCT adjusts the thermostat setting to save the most energy based
          on the received Emergency Event messages

  4       PCT is not responsive to customer input to override the Emergency
          Event temperature setting

  5       PCT waits until the Event End Time as indicated by the Emergency
          Event message

  6       PCT returns to the operating state that existed prior to the
          Emergency Event message (Could be normal programmed schedule,
          holding a specific temperature, etc.)

  Notes   PCT will also respond to a Cancel Event message prior to the
          Event End Time

          With two temperature setting messages, the desired default
          response and acceptable programmable responses need to be well
          defined
  ------- -----------------------------------------------------------------

**Scenario 8: PCT receives Event message with address information**

  ------- -----------------------------------------------------------------
  1       Utility sends Event Message(s) with Addressing data in the
          message body (The exact message type is irrelevant for this use
          case)

  2       PCT receives Event Message with Addressing information from the
          Utility Communication Infrastructure

  3       PCT compares received Addressing data with the PCT\'s stored
          address information

  4       PCT determines that it is an intended Event Message recipient

  5       PCT responds to Event Message according to the message type and
          the PCT\'s programming

  Notes   Title 24 indicates that accepting and acting on Addressing data
          is mandatory for the PCT. The utility is not required to send
          Addressing data.

          \"Addressing data\" refers to the Common Data Class that is
          included as part of messages sent by utilities to invoke a power
          saving response

          \"address information\" refers to the information that must be
          input into a PCT that defines a particular PCT\'s actual address
  ------- -----------------------------------------------------------------

# Annex B: Glossary

**Acronyms**

-   A/C Air Conditioning

-   ACSI Abstract Communications Service Interface

-   AMI Advanced Metering Infrastructure

-   AW Advisory Warning

-   CDC Common Data Class

-   CEC California Energy Commission

-   CI Commercial / Industrial

-   CIS Customer information System

-   CPP Critical Peak Pricing

-   CPUC California Public Utility Exchange

-   DES Data Encryption Standard

-   DR Demand Response

-   DRI Demand Responsive Infrastructure

-   EE Energy Efficiency

-   HVAC Heating, Ventilation, and Air Conditioning

-   IETF Internet Engineering Task Force

-   IOU Investor Owned Utility

-   ISO Independent System Operator

-   LCD Liquid Crystal Display

-   LED Light Emitting Diode

-   MD5 Message Digest 5

-   MMC Multi-Media Card

-   NEMA National Electrical Manufacturers Association

-   NRSC National Radio Systems Committee

-   NTP Network Time Protocol

-   PAM Price Alert Map

-   PCT Programmable Communicating Thermostat

-   PRD Price Responsive Device

-   RFC Request for Comments

-   SDIO Secure Digital Input / Output

-   RBDS Radio Broadcast Data System

-   RX Receive

-   SHA1 Secure Hash Algorithm 1

-   SNTP Simple Network Time Protocol

-   SPMS Statewide Power Management System

-   SPI Serial Peripheral Interface

-   TX Transmit

-   UCI Utility Communications Interface

-   UML Unified Modeling Language

-   XML eXtensible Mark-up Language

**Terms**

-   **Attribute:**

-   **California State Reliability Exchange:**

-   **Critical Peak Advisory:**

-   **Critical Peak Price Event:**

-   **Emergency Event:** An emergency event is issued through the
    utility communications network to PCTs when energy system
    reliability problems require a curtailment of residential energy use
    through temporary adjustment of thermostat settings. Emergency
    events make a temporary adjustment to a customer's temperature
    setpoint to lower energy use during a specified period.

-   **Hash:** A hash value (or simply hash), also called a message
    digest, is a number generated from a string of text. The hash is
    substantially smaller than the text itself, and is generated by a
    formula in such a way that it is extremely unlikely that some other
    text will produce the same hash value.

-   **Heat Pump:** A device that warms or cools a building by
    transferring heat from a relatively low-temperature reservoir to one
    at a higher temperature.

-   **Implementation Profile:**

-   **Price Event:** A price event is issued through the utility
    communications network to PCTs when energy supplies become tight
    when compared with energy demand. Customer PCTs receive this event
    and use pre-programmed adjustments provided by customers to lower
    energy use during such periods. In the future, once a smart meter
    has been installed at the customer's premises, energy charges may be
    raised during price events to reflect higher energy costs that the
    utility must pay to increase energy supply.

-   **Protocol-Level Services:**

-   **Reliability Event:**

-   **Service Model:**

-   **Stage 0 Event:**

-   **Stage 1 Event:**

-   **Stage 2 Event:**

-   **Stage 3 Event:**

-   **Stage 4 Event:**

-   **Transaction:**

-   **Transaction Sequence:**

# Annex C: UC Berkeley PCT Research Report

"Summary of HVAC and Expansion Port Analysis"

# Annex D: Other Publications

# Annex E: Title 24 Language (Final Draft -- Rev 29f) 

The full text of the Title 24 follows ...

**(i) Thermostats** -- All heating and/or cooling systems shall have a
Programmable Communicating Thermostat (PCT) that meets the requirements
of Subsections 112(c)(1) and 112(c)(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 Radio Data System (RDS) communications device that is
compatible with the default statewide DR communications system, 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.

> **Price Events** -- The PCT shall be shipped with default price-event
> offsets of +4°F for cooling and -4°F for heating enabled; however,
> customers shall be able to change the offsets and thermostat settings
> at any time during price 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. The PCT shall also be equipped with the capability to
> allow customers to define setpoints for heating and cooling in
> response to price signals as an alternative to temperature-offsetting
> response, as described in Reference Joint Appendix 5.
>
> **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.

PCTs shall also have the following capabilities. Technical detail of
items A though E below shall be included in Reference Joint Appendix 5:

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.  At a minimum, standardize terminal mapping of terminal numbers 1-9.
    This approach must include 24 volt power supply, both analog and
    digital PCTs, and must support heat pumps with resistance heat
    strips and reversing valve in both residential and small commercial
    packaged units.

D.  Include the capability to randomize, over a 30-minute period after
    the end of an event, the time at which the thermostat returns to the
    programmed setpoint.

> E. Through user input be capable of addressability at the substation
> level or finer including individual PCT.

**EXCEPTION 1 to Section 112(c):** Gravity gas wall heaters, gravity
floor heaters, gravity room heaters, non-central electric heaters, room
air conditioners, wood stoves, fireplaces, and room air-conditioner heat
pumps need not comply with this requirement. Additionally, room
air-conditioner heat pumps need not comply with Section 112 (b). The
resulting increase in energy use due to elimination of the setback
thermostat shall be factored into the compliance analysis in accordance
with a method prescribed by the Executive Director.

**EXCEPTION 2 to Section 112(c):** Other devices within the heating and
cooling system, other communications systems or methods, or utility
specific devices determined to be capable of providing equivalent demand
response functionality described in Section 112(i) that is approved by
the Executive Director.

# Annex F: The PCT Vision Document and Related Scenarios 

**(California Energy Commission -- Sept. 14, 2006)**

## Eliminating the Need for Rotating Outages through Statewide Air-Conditioning Load Control with Programmable Communicating Thermostats (PCTs)

The California Energy Commission is planning to mandate programmable
communicating thermostats (PCTs) for all central air-conditioning units
through building standards, appliance standards, load management
standards, or some combination thereof. This effort is being undertaken
to reduce or eliminate the need for rotating outages through temporary
reductions in air-conditioning services during Stage III system
emergencies. In addition, customers could use this same technology to
voluntarily and automatically reduce load in response to dynamic rates
and incentive programs. An important aspect of this goal is that the
PCTs be compatible statewide, such that customers can purchase equipment
irrespective of utility service territory.

### Introduction and Overview

Under the authority of Sections 25402 and 25403.5 of the Public Resource
Code, the California Energy Commission (Energy Commission) is charged
with the responsibilities to develop and maintain standards for building
and appliance efficiency and load management. Under these authorities,
the Energy Commission is planning to mandate programmable communicating
thermostats (PCTs) to enable load control of air-conditioning (AC)
during Stage III emergencies. The "partial outages" (i.e. raising
thermostat setpoints) made feasible by this emergency program would
reduce or eliminate the need for full rotating outages. As currently
planned, the PCTs would also provide customers with the capability to
automatically reduce AC electricity use in response to dynamic rates and
incentive programs, where available. The recently completed Statewide
Pricing Pilot (SPP) and related pilots with San Diego Gas & Electric
(SDG&E) and Southern California Edison (SCE) have demonstrated the
effectiveness of communicating thermostats in achieving these goals.

PCTs or analogous technologies are envisioned to support system
reliability, dynamic pricing, and incentive programs, as follows.

1.  **[Mandatory Load Control]{.underline}** -- PCTs provide the option
    for electric service providers to exercise control over AC loads in
    all non-exempt customer facilities ***as a last resort to avoid
    rotating outages***. Customers cannot override mandatory load
    control events.

2.  [**Dynamic Pricing**]{.underline} -- Should critical-peak pricing
    (CPP) or real-time pricing (RTP) tariffs become available to small
    customers, PCTs would provide customers the option to reduce their
    electricity bills by voluntarily responding to CPP events or
    designated RTP thresholds.

3.  **[Incentive Programs]{.underline}** -- PCTs would provide customers
    the option to earn money through voluntary participation in load
    control and other demand response programs that pay for
    participation and/or performance.

### Why partial outages?

Partial outages are more economically efficient than rotating outages
because the effects of the outage are limited to the reduction of a
single discretionary service (in this case AC) rather than elimination
of all services (as occurs in rotating outages). As penetration of
enabling technologies increases, partial outages can also be more
equitable than full outages, which do not affect customers on exempt
circuits. (About half of circuits are exempt, with non-discretionary
loads like hospitals and police stations.)

### Why AC load control? 

-   AC load control has long been considered a viable strategy for
    reducing peak demand.

-   AC is a large system load made up of many small individual loads, so
    load drops can be very small, very large (up to 30% of California
    peak load) and anywhere in between.

-   AC is generally considered a discretionary load. For most homes and
    businesses, an increase of a few degrees will not significantly
    impact comfort or economics, particularly if it happens only during
    extreme emergencies (less than once per year).

-   AC programs can potentially target all sectors (residential,
    commercial and industrial).

### Why a thermostat?

PCTs can provide two benefits generally unattainable with conventional
AC-cycling programs:

-   PCTs allow customers to automate preferences for response to dynamic
    pricing.

-   Temperature-based control strategies are expected to equalize
    comfort impacts across customers, whereas cycling can unduly affect
    those with smaller AC units.

### How would the envisioned system work?

Customers with PCTs could participate in dynamic pricing and AC load
control programs offered by their service providers. In addition, PCTs
could be used to quickly drop AC load to avoid rotating outages.
Following is a description of how the system might work with 5 million
PCTs and a peak load of 50 GW.

1.  Customers take service under a critical peak pricing (CPP) rate. The
    underlying time-of-use rate provides customers with incentives to
    program the PCT to shift load from more expensive to less expensive
    time periods every day. When wholesale market prices meet designated
    thresholds, "critical-peak" prices are dispatched, automatically
    initiating any price-event control strategies programmed by the
    customer. Customers may choose not to respond to price-events.
    Together, these automated actions lower everyday peaks and initiate
    significant demand response when wholesale costs are high, helping
    to avoid Stage 1 emergencies. Potential load drop: \~1-4% of peak
    load statewide.[^6]

2.  Expected supply shortages trigger (a) public appeals for
    conservation and (b) CPP events if wholesale prices have not already
    triggered an event. Potential load drop: \~1-4% of peak load
    statewide.Error: Reference source not found

3.  Shrinking reserves trigger voluntary curtailment (non-firm load
    reduction), including interruptible and AC load control customers.
    Potential load drop: \~3% of peak load statewide.[^7]

4.  Further supply shortages trigger mandatory curtailment (firm load
    reduction) in the following order:

    i.  PCT temperature setup: \~1-15% potential load drop statewide[^8]

    ii. Rotating outages: 100% circuit load drop; \~1-4% load drop
        statewide[^9]

### What are the design requirements for PCTs?

The PCTs are envisioned to have the following features: (see also
Appendix A)

-   Standard connector to a wall-plate, to eliminate future needs for
    professional installation

-   Communications for control inbound to thermostat (one-way
    communications)

    -   Optional outbound (two-way) to service provider

    -   Optional outbound (three-way) to other appliances in the home

-   Addressable by utility, program and geographic area

-   Customer interface indicates system protection and bill management
    events

    -   Optional display of pricing and control levels

-   Allows signaling of continuous 1° load drops during events for
    maximum flexibility

-   Manages load rebound after control events

### What are the next steps?

There are several technical issues that need to be addressed before a
PCT system can be finalized.

#### Choose a statewide communications system

To ensure that PCTs are compatible statewide, a default statewide
communication system must be determined so manufacturers can design the
PCT hardware.

#### Choose a standard protocols for activating control

To ensure that PCTs are compatible statewide, standard protocols for
activating control must be determined so manufacturers can design the
PCT software.

#### Determine addressability needs

For mandatory load control, PCTs must be addressable in a way that is
compatible with ISO/utility control areas. For dynamic pricing, PCTs
must be addressable at the utility level, since tariffs are utility
specific. Future pricing schemes may require addressability at the nodal
level. To allow voluntary load control programs, PCTs must be
addressable at the program/utility level, since signals must activate
only those individual customers who have signed up for the program.

#### Plan for management of load impacts at the onset and conclusion of events

Some events will warrant gradual load impacts while others might require
immediate response. In both cases a smooth return of AC load to the
system is likely to be desirable. If these strategies are to be part of
the PCT software, they must be determined before PCTs can be produced.

#### Choose a mandatory load control strategy

> There are currently two options for mandatory control being discussed.
> One involves increasing PCT setpoints by a certain number of degrees
> (e.g. +4°F), while the other option involves setting all PCTs to the
> same setpoint (e.g. 80°F).

**A Vision of Demand Response -- 2015**

**Scenarios**

**California Energy Commission (CEC)**

**A Vision of Demand Response -- 2015**

## Scenario 1- Residential, Low User, Minimum Functionality, Special Exemptions

At 78 years old, Meg A Watts was excited about moving into her new
condominium in the Shady Acres Lawn Bowling and Mahjong Retirement
Community. Widowed a little over three years ago, her long-time home of
the past 35 years was just too large and too difficult and expensive to
maintain. Her grown children arranged to move her to a new home in the
southern part of California's central valley, where she would have
warmer weather and would be near her grandchildren. The cold Idaho
winters and high winter utility bills were difficult to manage on a
fixed income. Recent health problems that now required on-site 24-hour
remote monitoring equipment linked to her doctor's office just added to
her budget difficulties.

Her new condominium was substantially smaller than her old house in
Idaho. According to her son Less, the reduced size of her new condo
combined with all of the new energy efficient appliances, should lower
her utility bills substantially and make it much easier to live within
her budget. Less had called the utility in advance to arrange service
for his mother. They asked a few questions regarding her basic lifestyle
and home features and whether she qualified for any special exemptions.
As a result of that call, they mailed Less an information packet and
setup checklist.

### Day #1: Normal Operations / Anticipated Critical Peak Conditions

#### Scenario -- Testing the PCT

Preconditions: PCT is installed and receiving communications from the
Utility Communication Infrastructure (UCI). Yellow light is lit
indicating successful communication.

1.  Customer presses and holds override (or dedicated test) button on
    PCT for 3 seconds.

2.  PCT activates internal test routine.

3.  PCT blue light turns on and flashes indicating a future economic
    critical price event. (Example duration: approx. 5 seconds.)

4.  PCT blue light stops flashing and remains steadily on indicating
    economic critical price event is underway. (Example duration:
    approx. 5 seconds.)

5.  PCT blue light remains on and red light begins to flash indicating
    Stage 1 emergency. (Example duration: approx. 5 seconds.)

6.  PCT blue light remains on, red light stops flashing and remains
    steadily on indicating Stage 2 emergency. (Example duration: approx.
    5 seconds.)

7.  PCT blue and red lights turn off.

8.  PCT test is complete.

#### Scenario -- Customer programs the PCT

Preconditions: PCT is installed

1.  Customer selects the pre-defined lifestyle schedule that is closest
    to their own schedule.

2.  Customer selects the desired comfort/economy setting.

3.  Customer modifies as necessary the schedule and heating/cooling
    levels.

4.  Customer modifies as necessary the pre-programmed critical pricing
    response.

5.  Customer disables, if authorized, the Stage 2 emergency response by
    using a code provided by the utility or other authorized personnel.

### Tuesday, July 21, 2015, 10:00am

#### What the Customer Sees

Meg and her son Less made a pre-move in visit to her new home to setup
the various utility, communication, and other accounts and to acquaint
her with the operation of her new appliances. Meg was not a big fan of
computers and automation and was initially overwhelmed by the many
automation features of her new home, especially this new thermostat she
read about. Less, assured her it was all quite simple, led her to the
wall where the thermostat was mounted, took out the checklist provided
by the utility and proceeded to show her how it worked.

Her son Less explained that about ten years ago the CPUC adopted new
rate structures that charged customers what he called a critical peak
rate (CPP). Most of the time she would be charged under a simple
time-of-use rate augmented by a supplemental charge that reflected high
utility cost or emergency situations. He assured Meg that it was
actually a pretty good deal. As he explained it, during the summer
months, her electric utility costs would be significantly lower during
late evening to early morning hours and higher during the mid-afternoon
period when most people were cooling their homes. If the demand for
energy ever got high enough to trigger a high-cost situation or
threatened the utility's ability to provide power, they would send out a
signal alerting all customer automation and notification devices to a
critical peak price. Less explained that most of the time customers were
given 12-24 hours advanced notice of any pending critical peak prices,
however, sometimes during emergencies customers were given no advanced
notice -- which was the reason customers automated their response
through the new thermostat.

Less explained how her thermostat would automatically receive critical
peak price and emergency signals and automatically make minor
adjustments based on her comfort settings. As part of his explanation,
Less pointed out the three LED displays on her thermostat and explained
to Meg what each light meant. The yellow light, which was currently lit,
indicated that the thermostat was active, working properly and currently
receiving a utility test and price signal. He showed her the little
sticker attached to the thermostat that provided instructions for
calling the manufacturer if the yellow light should ever go out or if
the thermostat malfunctioned in any other way.

Using the checklist, Less instructed Meg to push the Override button and
hold it for a few seconds to trigger a test routine. A blue light next
to the yellow light came on and slowly started flashing. Following the
checklist, Less explained this light would be activated when the utility
knew in advance, like the next day, that there would be a critical peak
price. After a few seconds, the blue light stopped flashing and stayed
lit -- he explained that a solid blue light meant the critical peak
price was actually in effect. Finally, after a few seconds a third red
light started to slowly flash. Less explained that this meant there was
something the checklist referred to as a Stage 1 system emergency. This
also triggered a critical peak price and the same pre-programmed
reaction from her thermostat. Finally, the red light stopped flashing
and stayed lit. Less explained that a steady red light meant there was a
very serious Stage 2 power emergency, which meant that the utility was
just one step away from rotating outages - when all of her power would
be turned off. Meg did not need a more detailed explanation. She had
been visiting Less and his family in the summer of 2000 and vividly
remembered the blackouts.

After Less finished his explanation of her thermostat display, he
proceeded to the next section of the checklist and told her she had
three options to choose from in setting up her thermostat.

-   [Option 1: Accept with the Default Settings]{.underline} -- Less
    explained that these new thermostats were a little different than
    what she had in her old home. According to Less they pre-programmed
    and ready to go out of the box with default lifestyle (time),
    comfort and economy schedules. As he explained it, lifestyle
    schedules used pre-set time settings to reflect typical work, stay
    at home or holiday operating times. Comfort schedules would maintain
    a default 75^0^ temperature setting unless Meg pushed the "Warmer"
    or "Cooler" arrow buttons. Pushing these buttons would raise or
    lower her thermostat settings for each lifestyle time block in fixed
    increments until she got her comfort to an acceptable level. Less
    explained that the economy schedule was a way for Meg to balance her
    comfort settings with potential bill savings. Economy settings
    determined how much her thermostat setting would change in response
    to the critical peak and emergency Stage 1 alert signals. If she did
    nothing the defaults would automatically change her thermostat
    setting by a minimum two degrees in summer months or lower it by the
    same amount in winter months in response to critical peak price or
    an emergency signals. Less showed Meg the information on the
    comfort-bill savings information provided on the utility checklist.
    According to the utility, the default economy settings should
    provide the typical customer with a 5% reduction in their monthly
    bill with no noticeable comfort impacts. In Meg's case, the utility
    estimated that a 5% savings would translate into \$3.00 to \$4.00
    each month. Changing to the "Moderate" economy setting would raise
    average monthly savings to 7-8% and result in a few hours of warmer
    or cooler conditions. The "Super Saver" economy setting could
    produce savings as high as 15% but would also result in a little
    greater discomfort.

-   [Option 2: Modify the Default Lifestyle Settings]{.underline} - Less
    pushed the override button one more time and scrolled through the
    lifestyle settings pre-programmed into the thermostat. The lifestyle
    settings provided several common work, vacation, and other
    schedules. Because this was a retirement community, the thermostat
    default was pre-programmed by the builder for a weekday and weekend
    "At Home" schedule, with the minimum critical peak price response.
    Meg could easily change the start and end time of any schedule to
    suit her needs or change the thermostat response if she wanted to
    increase or decrease her critical peak savings on her electric bill.

> Less also showed Meg that the setup routine allowed her to push the
> override button and automatically disable the critical peak price and
> Stage 1 emergency response indicated by the blue and red warning
> lights. Disabling the price response option during the setup process
> meant her thermostat and appliances would operate normally all the
> time and she would pay whatever it cost for the energy. Less also
> pointed out that she could leave the automatic price response program
> alone and just push the override button if she ever became
> uncomfortable or inconvenienced during a pricing event.
>
> Less noticed that the utility provided checklist also included
> estimated billing information for his mother's new condo, apparently
> based on information he provided during his phone call to activate her
> new account. The utility estimated that his mothers new home would
> probably be classified as a "low user" under the 130% of baseline
> legislation. As a result of an innovative change to the legislation
> Meg's monthly bill would charge her either the subsidized capped rate
> or the CPP rate, whichever was lower. The utility called this the Low
> Bill Guarantee Option.
>
> Meg took Less' recommendation and decided to try the default CPP
> pre-programmed lifestyle settings. Pushing a single button to override
> any automated CPP response was easy enough and the Low Bill Guarantee
> Option provided reasonable financial protection. Meg stood to gain
> financially if everything worked right. With the minimal response
> settings pre-programmed into her thermostat, the utility estimates Meg
> should pay about 15% less than she would under the subsidized 130%
> baseline rate.

-   [Option 3: Disable the Stage 2 Emergency Setting -]{.underline}
    According to the setup checklist, Less noticed that this option was
    limited to individuals with health and other disabilities that might
    be adversely impacted by any of the Stage 2 emergency response
    actions. According to the checklist, the information he provided to
    the utility regarding his mothers medical monitoring and alert
    equipment during the account setup process qualified her for the
    exemption. With her medical conditions, exposure to extreme heat
    situations that might result from any prolonged loss of use of her
    air conditioning, might pose a health problem.

> Less explained to Meg that during a Stage 2 alert, the utility could
> substantially curtail everyone's air conditioner or heating systems
> for brief periods of time if necessary to avoid rotating outages.
> However, Less also explained that Meg's medical monitoring equipment
> qualified her for an exemption.
>
> The checklist included a highlighted box with what looked like a
> special bar code printed in one corner. Following the instructions,
> Less was directed to hold the bar code within six inches of the
> thermostat, hold down the override button and wait for an
> acknowledgment signal, indicated when all three check lights would
> flash once, stay lit for about three seconds and then go back to their
> normal mode. According to the checklist, the bar code was really a
> printed radio frequency identification tag that was programmed for a
> one-time exemption. Less followed the instructions and noticed that
> the yellow, blue and red lights flashed once, stayed on for about 2-3
> seconds and then went back to a normal mode, with the yellow light on
> and the red and blue lights off.

#### What the Customer Did Not See

When Less Watts called the utility to activate his mother's account, the
customer service representatives automatically went through an automated
pre-service interview. The interview gathered the basic information to
support their billing process. It also asked a few very simple questions
to identify any medical or other special circumstances that might exempt
the customer from the Stage 2 involuntary curtailment of their HVAC
systems. Identifying customer locations with critical medical
information also allowed the utility to assign a higher priority to
preventative maintenance and outage incidents.

When Less indicated that medical monitoring equipment would be present,
the customer service representative authorized a medical exemption to
Stage 2 involuntary curtailment of Meg's HVAC systems. This
authorization caused a capacitor-activated radio frequency
identification (RFID) tag to be printed on the new customer Service
Initiation Checklist. This RFID tag was designed to be good for one use
after which it would become inactive and unusable. The RFID tag
functioned like an exemption key, however it would not become active
until the PCT received its first "Price/Test Signal".

The Price/Test Signal was dispatched by the utility several times each
hour. This signal provided the actual price included in the default CPP
rate, so in effect it acted like a real-time price. The signal also
included location specific information designed to allow the targeting
of control and price/emergency actions on individual substations and
feeders, a time stamp to continually synchronize the PCT and data
concentrators supporting their advanced metering (AMI) data collection
effort, and other maintenance information used by utility field crews to
support preventative and outage restoration. The price signal
information also was used to support utility and third party information
services like real-time customer displays of usage and actual cost.

The use of PCT's and the ability to assign individual exemptions
provided the utility with tremendous flexibility to dispatch very
limited HVAC curtailments, control a substantial amount of load and
generally avoid supply or congestion induced events that in the past
might require rotating outages. The involuntary HVAC curtailments
dispatched in prior Stage 2 alerts rarely reduced customer usage as much
as the original air conditioner load control programs.

Using basic occupancy information and Meg's address, the utility was
also able to call up the electricity usage history from her condo's
prior owner. This information provided them with the information they
needed to include estimated billing and savings information on the
Service Initiation Checklist they would send to Meg.

### Tuesday, July 21, 2015, 10:20am

Just as Less and his mother were finishing up at the thermostat, they
saw the flashing blue light come on. Meg looked at Less and asked if
that was something he did or was that a signal from the utility that
tomorrow could potentially be a critical peak price day. Less responded
that he was pretty sure it was a utility critical peak price alert,
although he said he had a way to confirm the signal. Less pulled out his
pocket communicator, a small hybrid device a little larger than the size
of a deck of cards that included voice, video, calendaring, email,
several entertainment options and electronic e-commerce applications.
The top portion of Less' display, reserved for high priority messages,
was flashing with a critical peak alert for Less' house from his
utility. Less held out the pocket communicator to show his mother the
flashing message. He mentioned that he had programmed his home systems
to automatically forward all critical messages to him via his pocket
communicator.

Less told his mother there were other ways she could confirm the price
signal if he wasn't around. He told her the utility also had an
arrangement with local television news services and newspapers to
publish or announce information on pending critical peak periods and
other emergency situations. Local television stations usually displayed
a utility icon somewhere on the screen during their news broadcasts.
Newspapers usually published the same icon in a banner at the top of the
front page.

**Day #2: Critical Peak / Emergency Conditions**

#### Scenario -- Critical peak pricing (One way communications)

Preconditions: PCT is installed and programmed. PCT is receiving
communications from the Utility Communication Infrastructure (UCI). PCT
blue light is flashing indicating an upcoming critical peak pricing
event.

> 1a. Utility transmits critical peak pricing message with a temperature
> setback using the UCI to groups of customers.
>
> OR
>
> 1b. Utility transmits critical peak pricing message with energy
> pricing data using the UCI to groups of customers.

2.  PCT receives message via UCI indicating critical peak pricing is now
    in effect.

3.  PCT waits a random period of time between 0 and 15 minutes.

> 4a. PCT changes temperature setting according to the received message.
> (e.g. The utility price message requests a 2 degree setback.)
>
> OR
>
> 4b. PCT changes temperature setting according to the PCT's programmed
> price message response. (e.g. A 4 degree setback is the default PCT
> response, but the customer has changed it to 3 degrees for higher
> comfort.)
>
> 5\. PCT emits a beep and sets the blue light to be constantly on.
>
> 6\. PCT remains responsive to customer input to override the utility
> setback.
>
> 7\. PCT adjusts temperature according to normal customer schedule
> maintaining the programmed price responsive temperature setback.

8\. PCT waits for a period of time as indicated by the received message.

9.  PCT returns temperature setting to customer's normally scheduled
    setting and turns off the blue light.

Alternate Steps

> 3a. PCT does not wait random period of time due to nature of received
> message or receipt of multiple utility messages that indicate an
> immediate start.
>
> 4c. PCT does not change temperature due to customer's modification of
> PCT critical peak price response.
>
> 8a. PCT receives message from utility via UCI indicating the end of
> the critical peak pricing period.

#### Scenario -- Stage 1 emergency (One way communications)

Preconditions: PCT is installed and programmed. PCT is receiving
communications from the Utility Communication Infrastructure (UCI).

> 1a. Utility transmits a Stage 1 emergency message with a temperature
> setback using the UCI to groups of customers.
>
> OR
>
> 1b. Utility transmits a Stage 1 emergency message with an absolute
> temperature setting using the UCI to groups of customers.

2.  PCT receives Stage 1 emergency message via UCI.

> 3\. PCT changes temperature setting according to the received message.
> (e.g. The utility emergency message requests a 4 degree setback or the
> absolute temperature is set to 79 degrees.)
>
> 4\. PCT emits a beep and sets the red light to flash on and off.
>
> 5\. PCT remains responsive to customer input to override the utility
> setback.
>
> 6\. PCT adjusts temperature according to normal customer schedule
> maintaining the programmed Stage 1 emergency temperature setback.

7\. PCT waits for a period of time as indicated by the received message.

8.  PCT returns temperature setting to customer's normally scheduled
    setting and turns off the red light.

Alternate Steps

> 3a. PCT does not change temperature due to customer's modification of
> PCT Stage 1 emergency response.
>
> 7a. PCT receives message from utility via UCI indicating the end of
> the Stage 1 emergency period.

#### Scenario -- Stage 2 emergency (One way communications)

Preconditions: PCT is installed and programmed. PCT is receiving
communications from the Utility Communication Infrastructure (UCI).

> 1a. Utility transmits a Stage 2 emergency message with a temperature
> setback using the UCI to groups of customers.
>
> OR
>
> 1b. Utility transmits a Stage 2 emergency message with an absolute
> temperature setting using the UCI to groups of customers.

2.  PCT receives Stage 2 emergency message via UCI.

> 3\. PCT changes temperature setting according to the received message.
> (e.g. The utility emergency message requests a 4 degree setback or the
> absolute temperature is set to 80 degrees.)
>
> 4\. PCT emits a beep and turns the red light on.
>
> 5\. PCT becomes unresponsive to customer input to override the utility
> setback.

6\. PCT waits for a period of time as indicated by the received message.

7.  PCT returns temperature setting to customer's normally scheduled
    setting and turns off the red light.

Alternate Steps

> 3a. PCT does not change temperature due to customer's modification of
> PCT Stage 2 emergency response. (e.g. Medical exemption)
>
> 6a. PCT receives message from utility via UCI indicating the end of
> the Stage 2 emergency period.

### Wednesday, July 22, 2015, 8:30 am

Reading the local newspaper and watching the early morning news on TV
while enjoying breakfast in her new home, Meg noticed a small banner in
the upper right corner of the front page announcing that today would be
a critical peak day. There was even a reference to a later section of
the newspaper that provided a "Helpful Hints" list of things people
could do to save money. The TV weather report indicated that the heat
wave was continuing, forecasting another day with temperatures exceeding
100^0^. As she watched the weather report Meg noticed a similar
"Critical Peak Alert" banner superimposed in a corner of the TV screen.

When she checked the LEDs on her thermostat she noticed that the blue
light was still flashing. Although she still felt a little uncertain
regarding how this new automated response stuff would work, the
information provided by the newspaper and local TV station seemed to
demonstrate a rather comforting level of coordination. It seemed like
the whole community was pulling together to help keep down costs and
avoid problems. Meg was feeling pretty comfortable with her new home.

### Wednesday, July 22, 2015, 2:30 pm

#### What the Customer Sees

Meg had just retuned from the local grocery store and was unpacking when
she heard a brief audible "beep" that appeared to come from her
thermostat. When she checked, she noticed that the blue LED had stopped
flashing and was now fully lit. According to Less, this meant that the
critical peak prices were now in effect, which should trigger an
automatic response from her air conditioning system. From the checklist
that Less left with her she knew that her thermostat was set to 75^0^
but now it read 76^0^. Meg was actually pretty impressed, the thermostat
had automatically responded just as Less had described. Meg went back to
unpacking her groceries but mentally reminded herself to take another
look a little later to make sure everything was still working right.

#### What the Customer Did Not See

Meg's thermostat was responding to a single secure virtual public
network (VPN) Internet signal that originated over 400 miles away
generated by the California ISO in a signal to her local utility when
the wholesale cost of energy exceeded a distribution area critical peak
threshold value for the Southern region of her central valley community.
The ISO was not only monitoring wholesale prices, it and Meg's local
utility were also simultaneously using the Statewide Power Management
System (SPMS) to monitor in real-time the actual load and system
harmonics on almost all major substations and distribution circuits. The
ISO critical peak price signal was automatically dispatched based on
algorithms that balance the wholesale costs with other information
regarding congestion and potential reliability features for each
monitored substation and distribution circuit. The California ISO signal
was received almost instantaneously by Meg's host utility and was
instantaneously passed through to their critical peak broadcast system
which uses a side band of several public radio and television stations
to trigger customer thermostats and other price responsive devices.
Passing the critical peak signals through each utility provides local
utilities with an opportunity to intervene and adjust the dispatch for
any maintenance or other special activity that might be jeopardized by
an untimely price or reliability signal. Utility operators had not
flagged any of the target areas for intervention, consequently the ISO
signal was passed through without delay.

Within 3-5 seconds the critical peak price signals had been received by
approximately 1.5 million residences and businesses, representing
approximately 12 GW of HVAC load. Price and reliability conditions were
not yet considered sever. Isograms established over several years of
real-time load monitoring indicated that voluntary customer price
response should provide more than sufficient load relief to mitigate
current problems. Consequently the ISO dispatch was statistically
targeted to dynamically configured groups of customers within the target
area to produce a minimum 1^0^ change in HVAC setting at any customer
site. ISO algorithms were designed to dynamically configure customer
groups and the control intensity to just meet the system need. Real-time
monitoring creates a closed-loop response that either ratchets the
control strategy up or down based on actual measured customer response.

The critical peak signals dispatched by the ISO and local utility
trigger a minimum one-hour control strategy from each thermostat and
price responsive device based on CEC design guidelines incorporated into
the Building and Appliance Standards. The design guidelines specify two
basic parameters that each device must meet, specifically:

-   [A minimum one-hour average control response]{.underline}.
    Specifying a 60-minute average control period minimizes the number
    of signals that need to be communicated and also avoids unnecessary
    short cycling of customer loads. In addition, the control period is
    internally randomized to average 60-minutes in duration, however,
    actual durations will vary between 45-75 minutes. Randomizing the
    duration of control helps balance returning load at the conclusion
    of each control event.

-   [Randomized control strategy start times]{.underline}. Normal
    critical peak price signals are received by each controllable
    thermostat and price responsive device almost instantaneously,
    however, activation of the device response is internally randomized
    over a 15-minute period. Randomizing the start times of each
    customer device helps balance both the initial load impacts and
    returning load at the end of the control period. In emergencies,
    multiple simultaneous signals from the ISO or local utility will
    trigger an immediate, non-random instantaneous activation of the
    control strategy for all customer devices.

### Wednesday, July 22, 2015, 4:00 pm

#### What the Customer Sees

While entertaining several of her new neighbors, Meg heard another
audible beep coming from her thermostat. When she checked, the blue LED
was still lit and now the red LED was flashing. While it was still
reasonably comfortable in her home, the thermostat now showed a setting
of 77^0^. One of Meg's new neighbors explained that the local utility
must be having some problems. Meg remembered that the flashing red LED
meant that the utility was experiencing something called a Stage 1
system emergency. One of Megs new neighbors then stated that she had
programmed her thermostat to the "Super Saving" setting during these
critical peak events because of the money it saved on her monthly bill.
She said when it gets too warm, I just go to the clubhouse or mall for a
few hours. Meg decided to wait and see whether her home would become
uncomfortable.

Just as she was about to rejoin her new friends, there was another
audible beep from thermostat. Now the red light stopped flashing and
stayed lit. Meg knew from Less that this meant there was a much more
severe Stage 2 emergency. However, Meg also noticed that although her
thermostat setting did not change from 77^0^ the numbers were now
flashing. One of her neighbors said something must be wrong with Meg's
thermostat because when she gets a solid red light her thermostat
displays a flashing emergency symbol instead of a temperature setting.

One of Megs other neighbors chimed in and said, the flashing temperature
setting means that Meg must have a medical or other exemption. Meg
confirmed that indeed that was the case because of the medical equipment
she had in the bedroom that let her doctor and hospital remotely monitor
her heart conditions.

Once Meg's neighbors figured out that a Stage 2 emergency had been
called, they also realized that their air conditioning systems would
automatically be curtailed until the utility problems were corrected.
None of Meg's neighbors had a medical exemption. Reluctant to return to
homes that would soon be getting a little uncomfortable, Meg offered and
they all unanimously decided to stay a little longer. Besides, Meg's
home was a comfortable 77^0^.

Then they all started talking about how complex all this technology
stuff was. Meg was still confused and amazed over how what looked like a
bar code on a piece of paper could actually be a miniature radio.

#### What the Customer Did Not See

At 3:59 pm the Statewide Power Management System (SPMS) registered a
forced outage on a major supply point feeding the Southern central
valley area. Dispatch algorithms at the California ISO automatically
adjusted for the loss of load by instantaneously ramping up the customer
price response signals. The ramping process generated multiple radio
activation signals that (1) automatically bypassed local utility
intervention and (2) instantaneously realigned customer groups and
synchronized another round of 2^0^ HVAC temperature increases from all
controllable thermostat and price response devices. This latest round of
emergency signals overrode the internal randomizing routines in customer
control devices to intensify the load response. The dynamic realignment
of the customer groups allowed the ISO to focus more voluntary price
response on the most congested areas. Reserve margins were now below 7%
in certain geographic areas but holding steady.

At 4:03pm another forced outage triggered a Stage 2 alert. This time ISO
dispatch algorithms substantially ramped up the control algorithms to
temporarily impose mandatory reliability overrides on all non-exempt
customer HVAC loads. In this case, a severe distribution problem
required the HVAC loads in the target area to be locked out entirely for
the duration of the event. Almost instantly, the SPMS registered an
additional 2 GW of load relief on the impacted circuits, pushing system
reserve margins back above 7%.

Simultaneously, local utility systems dispatched electronic explanatory
warning messages to all major commercial and industrial customers as
well as others who had signed up for the notification service.
Announcements were also automatically dispatched to all radio and
television stations. Repair crews were also receiving information from
both the utility advanced metering (AMI) network and SPMS regarding
isolated customer and distribution feeder outages. Select crews received
emergency electronic work orders on Internet connected field tablets
that directed them to specific GPS coordinates corresponding to the
location of each outage.

### Wednesday, July 22, 2015, 6:35 pm

#### What the Customer Sees

Meg's first mahjong game was breaking up and her new neighbors were
starting to leave when there was another beep from her thermostat. The
yellow LED was now the only one of the three that was still lit. Both
the blue and red LED's were now off. Meg's thermostat was registering an
internal reading of 77^0^ but her internal setting was now back to 75^0^
. Apparently both the critical peak and emergency situations were over.
Meg and her neighbors just shrugged and went about their business.

#### What the Customer Did Not See

Both forced outage situations were quickly resolved by emergency utility
crews. By 5:45 pm power had been restored to all customer locations
reporting problems. Declining commercial loads combined with voluntary
and mandatory price/reliability response brought reserve margins back to
normal levels. Based on forecasts from the SPMS, Stage 2 emergency
signals were discontinued at 5:50pm. Forecasts showed that all customer
loads would return to their normal local operating state starting around
6:30pm.

No major outages were reported. Utility customer operating centers
reported no significant increase in call volume.

A Vision of Demand Response -- 2015

## Scenario 2 - Residential, High User, High End Options, Advanced Functionality

Less Watts is a 42-year-old electrical engineer. For the last 6 years he
has worked for the NanoScience Particle Energy Research and Popsicle
Company (NSPERPC), a high-tech manufacturing company he started with his
brother. He and his family live about five miles from his mother's new
condominium in a 4,200 square foot custom built home in an exclusive
neighborhood. Less is a true high-tech gadget guy. Much to the
consternation of his wife and children, Less has automated and monitored
every aspect of his home.

It turns out that Less' infatuation for technology is actually secondary
in importance to his quest to save money. When his utility introduced
critical peak pricing (CPP) about nine years ago and advertised how much
money customers could save, Less took it as a personal challenge. While
his initial efforts with utility recommended control devices produced
reasonable bill savings and few noticeable impacts on his family's
lifestyle or comfort, Less was convinced he could do better.

Less eventually discovered that his utility offered quite a few
information and technology options to assist with his Less could access
through any Internet connection, or (2) a hardware and software package
being made available through local branch libraries. Out of curiosity
Less decided to try the loaner package available from the library. The
package included a wireless tablet and several devices that looked like
extension plugs. According to the literature, the wireless tablet was a
full-fledged computer with several built-in communication links. With a
supplemental subscription fee, the display tablet provided access to a
near real-time utility database that included his household energy usage
and actual cumulative billing / cost information. Analysis and modeling
applications included with the tablet will allowed him to graphically
display his usage information, customize the analysis by inputting more
detailed house and appliance information, and benchmark his usage with
like homes in his own community. One of the most interesting
applications makes it possible for Less to monitor each major appliance
one-by-one and perform sophisticated economic evaluations that identify
when he should consider a more efficient replacement. This utility
provided application also creates a list of certified local suppliers
and installers. Applications included with the electronic tablet also
automatically complete and transmit electronic applications for special
rebates on new appliances that Less wants to purchase.

According to the literature, the plug extension devices represent an
innovative new technology. By plugging these plug extension devices into
the electrical socket and then plugging in his electric appliances, Less
could monitor in real-time, the load for anything that has an electric
cord. Each plug extension device had a letter code stenciled on one
surface. Plugging an appliance into a plug extension device
automatically brings up a window on the wireless tablet labeled with the
letter code corresponding to the stenciled code. The window displays in
real-time how much energy is being used by that appliance at that
moment. By choosing the right options, Less can integrate these
individually monitored loads with his total house load. Less is also
provided with options to download all the data and reports wirelessly to
his own computer.

The first time Less checked out the electronic tablet and load
monitoring package, he was almost beside himself with excitement. First
he monitored the big things like the refrigerator, furnace, washer and
dryer. He then monitored everything that was plugged into the wall
including his beside lamp, toaster oven, electric toothbrush and his
wife's lava lamp. Based on a rate analysis using the utility provided
applications, Less discovered that properly managing his cooling zones
and shifting load to off-peak time periods would substantially reduce
his electric bills. The display table also allowed Less to preview and
model new state-of-the-art high-tech appliances with built in demand
management features that could be wirelessly linked with a whole-house
energy management system. As a result of this evaluation, Less upgraded
his HVAC, refrigerator, washer, dryer and hot water heater. He also
subscribed to the advanced energy management, monitoring and information
services provided by the appliance manufacturer, which was part of a
real-time maintenance contract (described below).

The new HVAC system employed wireless technologies that eliminated the
need for a conventional wall-mounted thermostat. Instead, his new HVAC
system came with little stick-on temperature sensors about the size of a
quarter that he could mount anywhere in his house. The system also came
with a wireless display/control panel that could sit on a counter or
mount to a wall bracket. Besides managing his home energy use, the
display panel provided a wireless link to the Internet along with
several news and entertainment options. What most excited Less was the
fact that neither the display panel nor any of the remote sensors used
batteries -- all were using a new energy scavenging technology based on
visible light, temperature variations and vibration.

The HVAC system that Less purchased included a redesign of the home duct
system. Less divided his house into four zones and then retrofitted his
ductwork with controllable dampers and remote temperature sensors that
allowed him to establish different comfort settings for each zone. A
wireless display touch panel displayed a schematic of his entire house
with real-time monitoring of each zone. The compressor and heating units
came equipped with fully integrated electronics and internal programs
necessary to provide full compliance with the CEC price responsive
Building and Appliance standards. When he purchased the new HVAC system,
Less opted for a vendor offered premium monitoring, preventative
maintenance and home automation package. This advanced package required
a special hybrid Wimax bi-directional communication capability that
would allow the vendor to support remote system diagnostics, off-site
remote maintenance and a range of other appliance applications, as well
as enhancements to the State required price responsive and emergency
response functions.

For all of his other major appliances, Less opted for models that were
wirelessly linked to and controlled by the home energy monitoring and
maintenance package provided by his HVAC vendor. Linkages between the
appliances and the home automation system provided support for
pre-cooling, shifting water heater use to off-peak hours and low-power
critical peak interlocks for the washer, dryer and dishwasher. According
to the simulations provided by the HVAC vendor, Less could theoretically
reduce his peak summer month electric bills by up to 40%.

### Day #1: Normal Operations / Anticipated Critical Peak Conditions

#### Tuesday, July 21, 2015, 10:20am

#### Scenario -- Critical peak pricing notification (Two way communications)

Preconditions: Customer has a PCT/home energy management system able to
receive advanced Utility or Qualified Signal Provider communications.

1.  Utility transmits critical peak pricing alert to customers and other
    Qualified Signal Providers that provide customer notification
    services.

2.  Qualified Signal Provider transmits critical peak pricing alert and
    additional value added data to Customer.

3.  Customer's PCT/home energy management system receives critical peak
    pricing alert.

4.  Customer's PCT/home energy management system confirms receipt of
    alert message to Qualified Signal Provider.

5.  Customer's PCT/home energy management system provides notification
    to Customer using displays and other communicating devices.

#### What the Customer Sees

Less' wife Lesley was in the kitchen paying bills and monitoring local
news updates from a wireless display monitor when a blinking critical
peak alert appeared in the upper portion of the screen. The message
included a small icon provided through their appliance vendor home
energy management subscription. When Lesley tapped the message with her
finger, a window with supplemental information appeared. The message
indicated that the critical peak period was most likely to occur
tomorrow, Wednesday, July 22^nd^ and start between 2:00 to 3:00pm and
would last for about 120 minutes. The message also indicated that all
in-home systems and control settings were operational. There was also a
status message indicating that the operating systems, environmental
controls and energy management functions at Less' business (NSPERPC)
were online and also operating as planned. Lesley knew that Less would
get these messages automatically since he programmed the wireless
display to forward all messages to his pocket communicator.

#### What the Customer Did Not See

By 5:30am each morning the ISO operations center has received the first
of several real-time updates from the Statewide Power Management System
(SPMS). Real-time substation and feeder data, together with weather
forecasts, monitored system harmonics, historical circuit loading and
current trading data produce a forecast of potential system cost, market
price and system reliability conditions for a range of geographical and
critical transmission / distribution locations throughout the statewide
electrical network. With a continuing heat wave, several forced outages
and other supply constraints; the forecast anticipates potential
critical price conditions for the next day during the later afternoon
hours. As a result, by 10:00am that morning, the ISO has provided each
local utility with a critical peak alert and detailed forecast for
Wednesday, July 22^nd^.

After processing the ISO information, the local utility dispatched a
system wide critical peak alert through their communication providers
that are automatically received by all CEC compliant controllable
thermostats and price responsive devices.

Less Watts purchased appliances and subscribed to information and
management services that require a more sophistical communication
capability than that mandated in the basic CEC compliant devices;
consequently his systems do not receive the standard utility "Critical
Peak Alert". Less' vendor provides their own communication network that
receives the utility "Critical Peak Alert" and then passes it through to
each of their subscribers along with additional information necessary to
manage Less' preferences. Less' vendor received their certification as a
Qualified Signal Provider from the CPUC only after demonstrating they
could meet a specific list of performance criteria.

### Day #2: Critical Peak / Emergency Conditions

#### Wednesday, July 22, 2015, 8:30 am

#### Scenario -- Critical Peak / Emergency Event (Two way communications)

Preconditions: Customer PCT/home energy management system able to
receive advanced utility or vendor communications.

1.  Utility transmits a Stage 1 emergency message with a temperature
    setback to customers and other Qualified Signal Providers that
    provide customer notification services.

2.  Qualified Signal Provider transmits Stage 1 emergency message to
    Customer.

3.  Customer's PCT/home energy management system receives Stage 1
    emergency message.

4.  Customer's PCT/home energy management system confirms receipt of
    Stage 1 emergency message to Qualified Signal Provider.

5.  Customer's PCT/home energy management system changes temperature
    setting according to received message

6.  PCT remains responsive to customer input to override the utility
    temperature setback.

7.  Utility transmits a Stage 2 emergency message with a temperature
    setback to customers and other Qualified Signal Providers that
    provide customer notification services.

8.  Qualified Signal Provider transmits Stage 2 emergency message to
    Customer.

9.  Customer's PCT/home energy management system receives Stage 2
    emergency message.

10. Customer's PCT/home energy management system confirms receipt of
    Stage 2 emergency message to Qualified Signal Provider.

11. Customer's PCT/home energy management system changes temperature
    setting according to received message

12. Customer's PCT/home energy management system prevents changes to
    temperature setting for a specified period of time or until
    emergency event has ended.

13. Customer's PCT/home energy management system waits for specified
    period of time or until a emergency event message is received and
    then returns temperature setting to the normal program.

Less and Leslie Watts left for work around 7:30am a few minutes after
their kids ran out the door to catch the school bus. Although the house
was now empty, Less' energy management program is beginning the second
phase of his bill management routine. Phase 1 began around 4:00am, when
the water heater began pre-heating water in anticipation of the family's
regular morning schedule. Before she left for work, Leslie placed a load
of dirty clothes in the washing machine and filled the dishwasher.
Timers on both appliances were pre-set to start and complete their
cycles before the peak rating period began at 11:30am. Phase 2 of the
energy management schedule included the following:

> 8:30am -- The dishwasher starts its 90-minute cycle and the HVAC
> system begins pre-cooling Zone 1, which includes the kitchen and
> family dining areas. Pre-cooling lowers the temperature in Zone 1 from
> its normal 78^0^ set point to 72^0^ and then establishes a maximum set
> point of 80^0^ for the peak hours of 11:30am to 6:00pm. The
> pre-cooling start time is automatically determined by the home energy
> management system. The system automatically monitors inside and
> outside temperatures and determines that precooling will take about
> three hours and conclude just before the peak rating period begins at
> 11:30am. The dampers and sensors in HVAC Zones 2-4 have been
> programmed to keep temperatures at or below 76^0^ during. the
> pre-cooling period. The dampers will be closed and no cooling load
> will be provided to Zones 2-4 during the peak hours unless
> temperatures exceed 84^0^. The precooling schedule and minimum-maximum
> temperature settings were established by iterative routines in the
> vendor provided home energy management system.
>
> 9:45am - The water heater begins a heating cycle both to supply the
> washing machine that is scheduled to come on at 10:00am and to
> pre-heat water for the post peak period hours when the Watts family
> kids are cleaning up and preparing their evening meal.
>
> 10:00am -- The washing machine automatically begins its 45-minute
> cycle. Less used the home energy management system to interlock the
> operating times of the clothes washer and dishwasher to prevent them
> from coming on at the same time. While Less' utility rate doesn't
> provide any financial incentive to minimize off-peak demands, it
> seemed like the efficient thing to do.
>
> 11:30am The dishwasher, clothes washer and water heater are
> interlocked to stay off during the entire peak period. The HVAC system
> has completed its pre-cooling cycle with Zone 1 reporting a
> temperature of 72^0^ and Zones 2-4 reporting 76^0^ . The refrigerator
> automatically goes into low power mode. A light on the refrigerator
> lets the user know it is in a low power mode and to minimize how many
> times they open the door.

By 11:30 am, the Watts household load has been minimized and is
registering about 0.5kW, where it will stay until the peak period
concludes at 6:00pm. Zone temperatures, the status of each appliance and
the household load are displayed on the monitor sitting on the kitchen
counter.

#### Wednesday, July 22, 2015, 2:30 pm

The Watts house is quite. The display monitor emits an audible beep and
the message in the upper portion of the screen changes to report that a
critical peak period is now in effect.

#### Wednesday, July 22, 2015, 4:00 pm

The Watts house is still quite. The display monitor emits an audible
beep and the message in the upper portion of the screen now reports that
the local utility has called a Stage 1 system emergency. The Watts home
energy management system verifies that the appliance interlocks are
still active and all Zone temperatures are within the established
settings -- no action is required.

At 4:01pm the display monitor emitted a series of beeps. The message in
the upper screen begins flashing that a Stage 2 emergency is now in
effect. The Watts home energy management system, in compliance with
State code, automatically places a minimum 60-minute non-over-rideable
lock on the HVAC system.

#### Wednesday, July 22, 2015, 6:15 pm

At 6:15pm Less Watts and his two children arrive home. Both kids are hot
and dirty from after-school activities. They dash off to their rooms to
change into their bathing suits and then head out to the pool.
Temperatures in their bedrooms, in Zone 3, are registering 84^0^. On
their way through the kitchen to the pool both kids complain to their
father of being too hot. Less notices that the monitor is reporting a
Zone 1 (kitchen) temperature of 81^0^. He also notices the flashing
message in the upper portion of the screen reporting that a Stage 2
emergency is still in effect. Less grabs a cold drink from the
refrigerator and joins his kids in the pool.

At 6:35pm the display monitor emitted another audible beep and the
message changed to report that the Stage 2 emergency was over. The Watts
home energy management system slowly brought up the HVAC system, first
in Zone 1 and then progressively in Zones 2-4. The refrigerator went
back to normal operation and immediately began making ice and cooling
water.

When Leslie retuned home at 6:45pm, the kitchen temperature was
registering 79^0^. She quickly joined the rest of her family at the
pool.

A Vision of Demand Response -- 2015

## Scenario 3 - Large Commercial / Industrial

MegaOffice is one of the largest high-rise commercial office complexes
in the downtown area. It provides premium office, conference and limited
retail space for top financial, legal and other service organizations.
In 2005 MegaOffice volunteered to participate in a field trial for a
demand response program referred to as "AutoDR". They were concerned
about the mandatory CPP rates being adopted as part of a CPUC regulatory
proceeding and wanted to investigate potential options that might
provide them with better energy cost management capabilities.
Participation in the AutoDR program turned out to be much more
productive than they anticipated.

As part of the recommissioning step, where all of their environmental,
internal operating systems and energy management system were tuned up
and recalibrated, they discovered a number of operating inefficiencies
that when corrected immediately resulted in substantial energy and bill
savings. They also were able to identify relatively easy measures to
support short-term price-based demand response that included resetting
cooling tower temperature set points, modulating air handling equipment
and temporarily turning off decorative and unnecessary lighting. The
AutoDR approach worked so well that MegaOffice expanded the automated
control systems to include more of their lighting and air handling
equipment.

In 2006 the distribution circuits supplying MegaOffice and other major
business establishments in the area encountered congestion problems that
resulted in several emergency calls from their utility warning of
potential short-term outages. Instead of just arbitrarily dropping load
or closing parts of their facilities as they had in the past, MegaOffice
and several other businesses activated their preprogrammed AutoDR
response. The resulting load reductions proved effective, buying
sufficient time for their utility to complete system upgrades and avoid
any disruptive outages.

Following those events, MegaOffice's utility instituted a revised AutoDR
package linked to CPP and to local system emergency conditions. By 2009
most business establishments with energy management systems had
established AutoDR programs capable of responding to CPP price or
utility emergency calls.

As part of their utility service package, MegaOffice was provided with
wireless access to the 15-minute interval data from the half-dozen
meters serving their facility. Internet links to a utility application
database also provided them with capability to monitor their actual bill
in near real-time. This information was linked into MegaOffice EMS and
simultaneously provided to both the corporate offices in Minnesota and
to the corporate energy consultants in Georgia.

Access to other utility provided applications and databases provided
MegaOffice with technical and financial tools for evaluating the latest
lighting, building automation and environmental systems.

### Day #1: Normal Operations / Anticipated Critical Peak Conditions

#### Tuesday, July 21, 2015, 5:30am

MegaOffice building supervisor was just completing his review of the
energy management system (EMS) daily diagnostic reports and their latest
quarterly corporate evaluation of the facility energy costs. All systems
were operating within acceptable parameters. Enhanced automation systems
installed last year now provided detailed diagnostics for every major
control point in the facility. These new systems also included several
automated 'self-healing' routines that automatically kept systems
properly calibrated.

#### 10:20am, Tuesday, July 21, 2015:

MegaOffices' building supervisor logged in a utility provided critical
peak alert for Wednesday, July 22^nd^ . To make sure they were prepared,
he initiated a diagnostic test of their new multi-level AutoDR response
strategies. Expanded automation of building systems now made it possible
for them to identify separate price and emergency response protocols.
Due to contractual requirements in their tenant leases, MegaOffice price
response strategy was designed to produce no more than a 10-15%
reduction in facility load. Iterative testing over the years showed that
a 10-15% short-term reduction was possible without violating lease
conditions or creating tenant discomfort or inconvenience. MegaOffices
emergency response strategies were designed to produce a much larger
20-30% reduction in facility load. Supplemental ISO emergency surcharges
added in to their underlying utility rate made it economically very
attractive to increase their emergency load reductions. MegaOffices'
reduction also improved the likelihood that any emergency would not
progress to a full rotating outage, with much more severe economic and
operating consequences. EMS diagnostics indicated that all AutoDR
routines were operating as planned.

Because of the day-ahead warning, the building supervisor activates a
pre-cooling strategy for the following day. Enthalpy controls will start
bringing in outside air to pre-cool the eastern zones of the building
during the early morning hours. Building HVAC systems will provide
supplemental cooling based on weather forecasts to bring the zone
temperatures to pre-defined set points that should be sufficient to let
MegaOffice substantially reduce demand through the peak period and coast
through at least part of the late afternoon critical peak hours.

### Day #2: Critical Peak / Emergency Conditions

#### Wednesday, July 22, 2015, 5:30 am

MegaOffice building supervisor has been monitoring the pre-cooling
effort that started about one hour earlier. Enthalpy controls started
bringing in cooler outside air lowering internal building space
temperatures from their standard 75^0^ to 70^0^. The eastern facing
zones are being pre-cooled first because they get the morning sun. All
remaining building zones will be rotated in until the pre-cooling
routine shifts over to building mechanical systems sometime before
9:00am.

#### Wednesday, July 22, 2015, 8:30 am

By 8:30am the entire MegaOffice facility has been pre-cooled to the
target set point. Email alerts from their local utility appear on the
supervisor display monitor confirming a critical peak likelihood later
in the afternoon.

By 10:00am, building mechanical systems are providing the first cooling
to some of the eastern facing retail areas which are experiencing higher
than expected foot traffic.

By 11:30am, the building EMS has settled into its normal peak-off peak
building management pattern.

#### Wednesday, July 22, 2015, 2:30 pm

At 2:30pm a message from the local utility alerts the building
supervisor that the critical peak price is now in effect.

MegaOffice AutoDR program began to slowly ramp down lighting levels in
most of the building public and private areas starting at 2:00pm so that
by 2:30pm most non-critical lighting was operating at about 65% of its
regular load. Under the AutoDR operating strategy, cooling tower set
points were raised, several of the less necessary elevator banks and all
decorative lighting and fountains have been curtailed. According to the
EMS, building load is leveling off at between 88-90% of the previous
days load. Temperatures in portions of the western zones are beginning
to rise above the normal set point target. Because of the critical peak,
temperatures will be allowed to rise to 77^0^ or 2^0^ above their normal
set point. The EMS forecasting applications project that because of the
outside heat, building mechanical systems will have to ramp back to full
capacity by 4:00pm.

#### Wednesday, July 22, 2015, 4:00 pm

At 4:00pm MegaOffice building supervisor received the Stage 1 emergency
message from his local utility. The Stage 1 alert automatically
triggered MegaOffice Phase 2 AutoDR energy management strategy.
Additional banks of non-essential lighting were turned off while others
were reduced to roughly 50% of their normal level. Cooling tower set
points and interior temperatures were raised another 2^0^ .

Within two minutes, the MegaOffice building supervisor received the
Stage 2 emergency message. The EMS automatically switched substantial
portions of the MegaOffice load to onsite gas powered emergency
generators, dropping the building load to roughly 45% or its normal
4:00pm demand.

By 4:30pm, the end-of-day routine was well under way with approximately
20% of the building tenants headed home. Building loads started their
normal late afternoon decline. By 5:30pm approximately 40% of the
building tenants were gone, load had declined substantially, interior
temperatures had stabilized and the emergency generators were being
ratcheted back to about 50% of their previous operating level.

#### Wednesday, July 22, 2015, 6:15 pm

At 6:35pm the Stage 2 alert ended, all the emergency generators were
shut down and MegaOffice EMS went into a recovery mode. All interior
temperatures and other building operating systems were back in full
evening operation by 8:00pm.

A Vision of Demand Response -- 2015

## Scenario 4 -- Utility Company

AMI systemwide implementation together with development of the SPMS has
provided the investor-owned and municipal utilities with a wide range of
system operating and customer service applications. As a result,
customer information systems (CIS), billing, outage management,
maintenance management, trading, and forecasting have all undergone
major application changes.

A variety of customer information services have been introduced,
including graphical bill analysis and Internet and hard copy
subscription-based load data and cost analysis. One of the more
innovative services is a wireless display that can be rented from local
utility and local community library facilities that provides customers
with near real-time load monitoring and billing information for their
account. Customers usually subscribe to this information service for one
or two months at a time when they have a billing problem due to a
unexplained usage patterns or when replacing a major appliance. Embedded
applications and data bases, accessible through the display device can
be used to help customers evaluate the potential bill impacts of various
appliance upgrade and other efficiency alternatives. Applications
actually allow customers to model the potential energy and cost impacts
on their facility, to identify potential rebates, store locations,
installers and financing options. Printed reports can be downloaded to
their own computer or mailed by the utility. Customers can also link
into the same utility databases and applications using their own
wireless displays or home computers and subscribe to the service for a
nominal cost.

### Day #1: Normal Operations / Anticipated Critical Peak Conditions

#### 10:00am, Tuesday, July 21, 2015:

As part of their normal daily operating procedure, customer service
representatives, distribution engineers and trading staff review the
forecasts of yesterday's operations along with 24, 48 and 72-hour
forecasts of weather and system load conditions at all major
transmission and distribution locations within their service territory.
ISO Advisory Warnings (AW) are also noted and logged.

Customer service representatives notice the forecasts predict a
continuation of the heat wave through the end of the week. Internal
supplemental forecasts identify a higher than acceptable potential for
critical peak cost increases. In addition, data monitoring activities
indicate that certain feeders are approaching threshold conditions that
might lead to unacceptable voltage and other reliability problems.

#### 10:15am, Tuesday, July 21, 2015:

While reviewing the daily operating reports, customer service
representatives received the ISO critical peak advisory for their
Southern Central Valley region. This automatically triggered a utility
generated "Critical Peak Alert". Critical peak alerts are broadcast
through their communication provider to all PRD's in the targeted
portion of their service area, posted to the utility web site, reported
in a banner in local newspapers and distributed to targeted critical
customer lists by email. Critical peak alerts provide customers with
advance notice of expected critical peak pricing events. They also
encourage customers to review their facility operating systems and make
sure their backup generation and AutoDR emergency response options are
in good working order. These alerts also provide customers with PRD
devices advance notice that higher prices may be forthcoming.

SPMS reports also highlighted several distribution feeders that were
potential candidates for heat and cooling load problems. As a result,
tree trimming and maintenance crews were redirected today to accelerate
scheduled work on the most severely impacted areas.

### Day #2: Critical Peak / Emergency Conditions

#### 11:01am, Wednesday, July 22, 2015

Critical peak price alerts for Thursday, July 23^rd^ are automatically
received by the customer operations center. Critical peak price alerts
automatically generate a series of computerized action plans that
identify price alert maps (PAM) by substation and feeder. Price alert
maps identify which groups of substations and feeders should receive
critical peak price alerts based on their relationship to supply, T&D
and existing system maintenance activity. Price alert maps also identify
and recommend customized dispatch strategies by substation and feeder
locations to account for the potential duration and intensity of
potential critical peak price alerts.

Operators carefully review the price alert maps and modify the
recommended strategies to reflect more current information regarding
distribution and other system maintenance activity. Ongoing transformer
replacement and tree trimming activities in two critical areas
necessitate modifications to the PAM to balance loads and avoid
interfering with critical upgrades.

#### 12:00 noon, Wednesday, July 22, 2015

Operations supervisors have reviewed and approved PAM's for Thursday,
July 23^rd^. Operators activate the PAM and critical peak price alerts
are automatically dispatched through a sideband of the State broadcast
system and through all registered signal providers to the targeted
substation and feeder locations as well as to licensed third-party
signal providers.

A Vision of Demand Response -- 2015

## Scenario 5 -- California ISO

Each morning, analysis models, linked into the real-time database
maintained by the Statewide Power Management System (SPMS) produce
dynamic reports comparing transmission, substation and selected feeder
loads for the previous five days with forecasted loads for the next
three days. The SPMS was actually designed as a series of independent
systems and databases that are maintained by each utility (investor
owned and municipal) linked through the Internet.

Analytical models at both the ISO and utilities, continually integrate
and evaluate generator availability, maintenance schedules, and outage
information together with weather, actual load, voltage and frequency,
and measurements of other system harmonics into hierarchical reports to
support resource trading desk and other system operating and emergency
activities. The SPMS reports provided to ISO system engineers include
substantially refined estimates of expected supply, demand and the
status of reserves throughout the state.

Automated routines under the SPMS conduct daily system tests to
calibrate PRD emergency capability by substation and select-feeder
locations. Equivalent to the notch tests conducted for the original air
conditioning load control programs back in the early 1980's and 1990's,
SPMS PRD daily tests randomly dispatch a minimized emergency signal that
either increases (summer) or decreases (winter) residential and CI HVAC
settings by two degrees (2^0^), just enough to temporarily drop each
connected load to allow measurement by real-time metering located on
each substation and feeder circuit. SPMS PRD test signals occur at
different times each day and at most last for minimum HVAC cycles, which
is usually less than 10 minutes. Interval load, temperature, voltage,
frequency and other system harmonics are automatically archived in a
master databases maintained by each utility. Utility master databases
are linked into the ISO via secure high-speed wireless Internet
connections.

The database of SPMS PRD test results accumulated over the last five
years provides the ISO with the capability to construct isograms that
estimate the emergency load available by hour and temperature at each
major feeder location. The database of isograms plotting PRD
controllable load are dynamically integrated into emergency dispatch
algorithms that allow system operators to target and scale emergency
load relief to specific feeder and delivery point needs.

Dynamic algorithms link to real-time monitoring of each targeted area
provide a closed loop confirmation and adjustment function to assure
achievement of emergency load objectives. Using threshold criteria to
trigger activation, dynamic algorithms use historical isograms to
automatically determine the optimum control strategy for each feeder.
Control strategies balance the HVAC temperature change and available
customer load necessary to protect the system. With real-time
monitoring, the dynamic algorithms can compare the actual load
reductions achieved with the load reductions needed and instantaneously
adjust the control strategies automatically upward or downward to
maintain system balance. Because of the large amount of load under
control, emergency PRD operations only rarely result in HVAC temperature
changes of more than one degree during a typical two-hour event and
generally no more than two degrees during a four-hour event.

Dynamic algorithms under ISO supervision, can automatically schedule
emergency PRD load reductions hours in advance to anticipate potential
loading problems due to supply demand imbalances or voltage and
frequency problems. Real-time monitoring under the SPMS also allows
fully automatic PRD dispatch based on threshold criteria during system
emergencies.

### Day #1: Normal Operations / Anticipated Critical Peak Conditions

#### 10:00am, Tuesday, July 21, 2015:

As part of their normal daily operating procedure, system engineers
review the forecasts of yesterday's operations along with 24, 48 and
72-hour forecasts of weather and system load conditions at all major
transmission and distribution locations.

Although parts of the state have been experiencing a prolonged heat
wave, forecasts do not yet highlight any immediate system imbalances or
potential emergency situations. Although supplies are tightening and
reserve margins and system costs are still within acceptable limits,
forced outages of several utility and customer resources are highlighted
by SPMS reports as a potential problem area. As a result, the forecasts
indicate that load, weather and supply conditions could trigger a
critical peak price event in the Southern Central Valley regions during
the hours from 3:00 to 5:00pm on. Wednesday, July 22^nd^.

Because of the tightening supply conditions and projected load
forecasts, at 10:05am the ISO authorized the issuance of critical peak
advisories through the California State Reliability Exchange
(Reliability Exchange) for all utilities in the affected regions
Critical Peak Advisories encourage utilities and customers to prioritize
critical system maintenance activities and tune up internal systems that
might be needed should prices and reliability conditions worsen. The ISO
critical peak advisories were dispatched through a secure Internet
connection to all utilities and other load serving entities.

### Day #2: Critial Peak / Emergency Conditions

#### 10:00am, Wednesday, July 22, 2015:

Due to restricted supply conditions, Cal ISO forecasts estimate 200-400
percent increases in peak hour prices for Thursday afternoon, July 23,
2015. Reserves on Tuesday briefly dipped below 10%. With today's
expected high temperatures and critical peak prices forecasts don't look
good for Thursday. Reserves are projected to be very close to the 7%
threshold and SPMS reports indicate that any additional forced outages
would trigger reliability events. SPMS monitoring shows that critical
congestion has now spread out of the Southern Central Valley region into
the entire Central Valley, the Southern desert and throughout the entire
LA basin.

Cal ISO system operation models estimate that customer price response
will produce peak load reductions of 8-12 percent, which should be more
than adequate to maintain system reserves. Continuously updated load and
system harmonic data from the real-time SPMS confirm that up to 25% of
targeted substation loads are available through the emergency PRD system
should supply and/or other system conditions worsen. Forecasts target
and identify specific substations and distribution points where supply /
congestion problems will be most severe.

#### 11:00am, Wednesday, July 22, 2015:

Cal ISO 24-hour price forecasts and a critical peak price alert for
Thursday, July 23^rd^ are automatically posted and dispatched via the
Internet to the California State Reliability Exchange (Reliability
Exchange). The Reliability Exchange is a secure Internet site maintained
by the ISO that provides open access to ISO price and reliability
forecasts on a weekly, daily and hourly basis accessible to energy
utilities, consumers and energy / demand response providers. Secure
portions of the Reliability Exchange provide automatic notification and
coordination between the State investor owned and municipal utilities
and licensed third-party signal providers.

A Vision of Demand Response -- 2015

## Scenario 6 -- California Public Utilities Commission

As a result of the CPUC decisions in 2006 that made Critical Peak
Pricing (CPP) the default tariff for all customers, demand response (DR)
and energy efficiency (EE) were now fully integrated into all customer
service agreements. The CPUC also updated utility outage management
plans to reflect the emergency system protection capability included
under CEC Building and Appliance standards for price responsive devices
(PRD) and functionality.

The time-of-use component of the CPP rate together with the critical
peak prices during an expected average year, provide customers with
clear incentives to evaluate efficiency investments. Incorporating the
critical peak prices in the tariff provides customers with clear
incentives to consider major appliance and other purchases that
accommodate load shifting and automatic reductions in response to either
price or reliability events.

Establishing CPP as a default tariff also simplified what had been a
twenty-year menu of continually changing utility sponsored DR programs.
Under the CPP tariff customer incentives come from avoiding the use of
expensive energy during critical peak times. Customer incentives are now
directly related to how each customer changes their energy own usage
pattern, not whether they sign up for a specific DR program. Paying
customer for performance rather than participation had several other
major positive impacts. First, because customers were now avoiding the
use of high cost energy, utility revenue requirements and rates actually
went down. Paying customer incentives out avoided utility costs actually
raised revenue requirements and rates. Most significantly, the
artificial boundaries imposed by previous rate DR program structures
were now eliminated, allowing each customer to do as much or as little
as they wanted in defining how they would respond. The CPP tariff
eliminated the overlapping incentives and restrictive participation
rules that characterized the previous mix of a rate and DR programs.
Implementation of the CPP tariff also eliminated many of the utility
sponsored EE subsidies.

A review of EE cost effectiveness revealed that CPP and the underlying
time-of-use rate actually improved the return on investment and
accelerated payback periods for most critical lighting and HVAC related
applications. As a result a variety of new subsidies were developed to
overcome purchase resistance and financing rather than long run cost
effectiveness. Utilities efforts to integrate EE and DR were now much
easier given the simplified price signals provided by CPP. Utilities EE
and DR activities switched from program management to customer
education, customer information services, the evaluation of alternative
automation and efficiency upgrades, and vendor and product referral
services -- efforts to emphasize and assist customer adaptation to the
CPP tariff.

Rate impact studies showed that CPP rates were easier for customers to
understand. Rate stability over the last nine years also provided more
certainty that made residential and commercial/industrial (CI)
investment in EE less risky for all major lighting, HVAC and facility
automation related modifications. Targeted subsidies for renewable and
distributed generation, facility automation, and other selected options
continued to be supported on an as-needed basis. A few ISO supported
reliability-based options also received continuing support.

The integration of DR and EE under the CPP rate also eliminated the
restrictions previously imposed on the Public Goods funds. While the
public goods charge was reduced by about two-thirds several years ago,
the remainder was now directed to support utility directed customer
education, information services, public interest research and product
evaluation and certification tasks in support of both EE and DR.

A recently released CPUC report confirmed that the price responsive
device (PRD) functionality standards imposed under the CEC Building and
Appliance Standards was now producing substantial energy conservation as
well as demand response impacts. While prior studies showed that
approximately 60-70% of all customers were not using the basic
programmable capability of their existing thermostat, opting instead to
manually control temperature settings, new utility studies now show that
only 25% of the customer population continue to operate in the manual
mode. The remaining 75% have implemented one or more of the default
lifestyle settings required by the Building and Appliance standards

Utility and ISO studies also conclude that customer price responsive,
non-reliability capability under the CPP tariff is producing 6-8%
reductions in gross summer peak system load in response to day-ahead
notification. Voluntary reliability responsive capability under the CPP
tariff and PRD operation is producing 12- 18% reductions in gross summer
system peak load in response to day-of notification.

Utility and ISO studies also confirm that system tests of PRD emergency,
non-override operations can consistently produce 30-35% reductions in
gross summer peak system load on selected feeders in high temperature
zones and 8-15% reductions in peak load on selected feeders in winter.

Utility outage management reports show steady reductions in outage
frequency, duration and better targeting of tree trimming and other
general maintenance dollars -- producing increases in net system
benefits over original projections from AMI and related business case
studies. Utility reports indicate reductions of almost 50% in unserved
kWh per outage due to faster recovery for the projected time period
to-date.

Load and reliability analysis for selected feeders continue to show
substantial potential for distributed generation at targeted office
parks and retail centers, based on enhanced customer monitoring of AMI
data.

As a result, CPUC decisions continue to authorize increases in the
allowed contribution of DR as a reliability resource under resource
adequacy guidelines.

Customer price response in conjunction with the use of PRD's to manage
distribution congestion resulted in much higher utilization rates for
base load generation and the elimination of most peaker plants. System
reliability measurements based on customer minutes of outage per year
showed almost continuous improvement over the last five years.

An emerging development was the recent formation of an industry driven
organization to investigate the potential for DR reliability-based
trading credits. Worsening transmission and distribution congestion in
several geographic areas spurred manufacturers and high tech companies
to evaluate options for further improving system reliability and power
quality. An industry funded report highlighted the opportunity created
by common transparent system wide rates and the success of PRD's. The
report points out that corporate subsidies to further improve non CI
price and reliability response on selected distribution circuits could
be less expensive than investing utility ratepayer funds or paying to
upgrade their own sites. The industry organization has indicated they
will be soon be filing an application for a targeted demonstration pilot
on a critical feeder in Northern California.

# Annex G: Material related to Joint IOU PCT Specifications using Two-Way Communications for Extended Functionality

## Annex G1: Digital Control Interface

## Annex G2: Reliability Event Commands

#### Reliability Event -- Change Temperature

  --------------------------------------------------------------------------------------
  **Reliability                                                                
  Event (change                                                                
  temperature)                                                                 
  Command**                                                                    
  --------------- ------------ ----------------------------------------------- ---------
  **Attribute     **Attr.      **Explanation**                                 **M/O**
  Name**          Type**                                                       

  **Data**                                                                     

  Command Code    INT8U        (ex: 3)                                         M

  Address         \<ADDR\>     Which PCTs should use this information (this    M
                               may be ignored)                                 

  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        M
                               cancellation)                                   

  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

#### Reliability Event -- Set Temperature

  ----------------------------------------------------------------------------------------
  **Reliability                                                                  
  Event (set                                                                     
  temperature)                                                                   
  Command**                                                                      
  ----------------- ------------ ----------------------------------------------- ---------
  **Attribute       **Attr.      **Explanation**                                 **M/O**
  Name**            Type**                                                       

  **Data**                                                                       

  Command Code      INT8U        (ex: 4)                                         M

  Address           \<ADDR\>     Which PCTs should use this information (this    M
                                 may be ignored)                                 

  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        M
                                 cancellation)                                   

  New_Temperature   INT16U       New temperature setpoint, in tenths of a degree M
                                 Celsius                                         

  Crypto            \<CRYPTO\>   Message integrity value                         O
  ----------------------------------------------------------------------------------------

#### Price Event Command -- Level Based

  ---------------------------------------------------------------------------------------
  **Price Event                                                                 
  Notification**                                                                
  ---------------- ------------ ----------------------------------------------- ---------
  **Attribute      **Attr.      **Explanation**                                 **M/O**
  Name**           Type**                                                       

  **Data**                                                                      

  Message_ID       \<MSG_ID\>   Sequential ID for this message                  M

  Command Code     INT8U        (ex: 22)                                        M

  Address          \<ADDR\>     Which PCTs should use this information (this    M
                                may be ignored)                                 

  Current Price    INT8U        Example: 1=normal price, 2=peak price,          M
  Level                         3=emergency price, etc.                         

  Crypto           \<CRYPTO\>   Message integrity value                         O
  ---------------------------------------------------------------------------------------

**Note:** This message takes effect immediately -- no intentional delay

## Annex G3: Message Commands for Joint IOU PCT Functionality using Two-Way Communications

(Previously referenced in Section 4.3.4)

The Joint IOU document describes additional features beyond the Title 24
PCT requirements which enhance the user interface of the PCT. Two
application enhancements are made: simple determination of the PCT
installation, and a direct display of the current price.

Upon installation of the PCT, the installer will want assurances that
the device is operating properly. The utilities are concerned that
customers will contact them upon PCT installation to determine whether
connectivity has been achieved. These calls can be avoided by having the
PCT indicate connectivity. This connectivity is detected by the presence
of received messages. The "connection operational" indicator on the PCT
can be activated quickly if messages are sent periodically to the PCT
(perhaps a few times per day). These are termed "keep-alive" messages.

The utilities have also recognized the fact that demand response can be
increased if the customer has direct knowledge of the cost of energy.
The concern, however, is that a display capable of indicating an exact
price adds significant cost to the PCT. Therefore, the utilities believe
that price levels (A-B-C), which are simpler to display, would be more
useful for the price sensitive PCT applications.

#### Status Request

  -------------------------------------------------------------------------------------
  **Keep-alive                                                                
  Command**                                                                   
  -------------- ------------ ----------------------------------------------- ---------
  **Attribute    **Attr.      **Explanation**                                 **M/O**
  Name**         Type**                                                       

  **Data**                                                                    

  Message_ID     \<MSG_ID\>   Sequential ID for this message                  M

  Command Code   INT8U        (ex: 27)                                        M

  Address        \<ADDR\>     Which PCTs should use this information (this    M
                              may be ignored)                                 

  Crypto         \<CRYPTO\>   Message integrity value                         O
  -------------------------------------------------------------------------------------

**Notes:** Request PCT response to confirm connectivity and availability

#### Update Firmware

  -------------------------------------------------------------------------------------
  **Keep-alive                                                                
  Command**                                                                   
  -------------- ------------ ----------------------------------------------- ---------
  **Attribute    **Attr.      **Explanation**                                 **M/O**
  Name**         Type**                                                       

  **Data**                                                                    

  Message_ID     \<MSG_ID\>   Sequential ID for this message                  M

  Command Code   INT8U        (ex: 28)                                        M

  Address        \<ADDR\>     Which PCTs should use this information (this    M
                              may be ignored)                                 

  Event_ID       \<EV_ID\>    Event ID used to uniquely identify this         M
                              firmware update                                 

  SW_Version     BSTR16       16 byte firmware version ID being uploaded      M

  Num_Blocks     INT16U       Total number of blocks in firmware update       M

  Block_ID       INT16U       This block number                               M

  Block_Data     BSTR1024     1024 byte firmware data block                   M

  Crypto         \<CRYPTO\>   Message integrity value                         O
  -------------------------------------------------------------------------------------

**Notes:** This message is used to send new firmware to the PCT. The
contents of the firmware data blocks are proprietary to the vendor. The
PCT should be capable of buffering all blocks received until a complete
new firmware image is received and validated at which point it will be
installed and activated. The PCT watchdog should be capable of reverting
to the last known good firmware image if a newly uploaded image fails to
operate properly upon activation. The sending system should retransmit
all blocks at least one -- preferably several times -- to ensure that
all PCT's have received the update. The PCT will ignore update commands
if already operating at that version. In two way systems, the status
message may be used to determine the currently running firmware version.

## Annex G4: Message Responses for Joint IOU PCT Functionality using Two-Way Communications

The addition of two-way communication capability can increase the
capabilities of the DR system. These improvements allow the utilities to
observe the response to DR signals by individual users. These messages
are transmitted from the PCT to the utility.

For example, the utility could receive a response when a valid request
has been received by the PCT. This response could include the actual
customer response to the DR signal. Another use for two-way
communications would be to indicate that communications had been
restored to the utility. This frequent occurrence of this signal would
indicate a pending failure in the communications system.

#### Price Message Acknowledgement

  ------------------------------------------------------------------------------------------
  **Price                                                                          
  Acknowledgement**                                                                
  ------------------- ------------ ----------------------------------------------- ---------
  **Attribute Name**  **Attr.      **Explanation**                                 **M/O**
                      Type**                                                       

  **Data**                                                                         

  Command Code        INT8U        (ex: 101)                                       M

  Address             \<ADDR\>     This indicates the PCT address / Customer ID    M

  Event_ID_Ack        \<EV_ID\>    Identifier of price event being acknowledged    M

  Action_Taken        INT8U        Ex: 1=accepted, 2=overridden, 3=in progress     M

  Action_Time         \<DTIME\>    Time stamp of action taken                      M

  New_Temperature     INT16U       New temperature setpoint, in tenths of a degree O
                                   Celsius                                         

  Temp_Change         INT8S        Amount setpoint has been changed (in tenths of  O
                                   a degree Celsius)                               

  Load_Reduction      INT16U       Estimated average amount of curtailed load in   O
                                   units of 100's of watts                         

  Crypto              \<CRYPTO\>   Message integrity value                         O
  ------------------------------------------------------------------------------------------

#### Reliability/Emergency Message Acknowledgement

  ------------------------------------------------------------------------------------------
  **Emergency                                                                      
  Acknowledgement**                                                                
  ------------------- ------------ ----------------------------------------------- ---------
  **Attribute Name**  **Attr.      **Explanation**                                 **M/O**
                      Type**                                                       

  **Data**                                                                         

  Command Code        INT8U        (ex: 102)                                       M

  Address             \<ADDR\>     This indicates the PCT address / Customer ID    M

  Event_ID_Ack        \<EV_ID\>    Identifier of price event being acknowledged    M

  Action_Taken        INT8U        Ex: 1=accepted, 4=exempt (e.g.: for medical     M
                                   reasons), 100=error_general,                    
                                   101=error_energy_increase, etc.                 

  Action_Time         \<DTIME\>    Time stamp of action taken                      M

  Load_Reduction      INT16U       Estimated average amount of curtailed load in   O
                                   units of 100's of watts                         

  Crypto              \<CRYPTO\>   Message integrity value                         O
  ------------------------------------------------------------------------------------------

#### Communications Established/Restored

  ----------------------------------------------------------------------------------------
  **Restoration**                                                                
  ----------------- ------------ ----------------------------------------------- ---------
  **Attribute       **Attr.      **Explanation**                                 **M/O**
  Name**            Type**                                                       

  **Data**                                                                       

  Command Code      INT8U        (ex: 103)                                       M

  Address           \<ADDR\>     This indicates the PCT address / Customer ID    M

  Crypto            \<CRYPTO\>   Message integrity value                         O
  ----------------------------------------------------------------------------------------

**Note:** This can be used to verify initial enrollment as well as basic
communications restoration logging.

#### Status Request Response

  ---------------------------------------------------------------------------------------------------
  **Restoration**                                                                           
  ----------------- ------------ ---------------------------------------------------------- ---------
  **Attribute       **Attr.      **Explanation**                                            **M/O**
  Name**            Type**                                                                  

  **Data**                                                                                  

  Command Code      INT8U        (ex: 104)                                                  M

  Address           \<ADDR\>     This indicates the PCT address / Customer ID               M

  Action_Taken      INT8U        Ex: 6=PCT OK, 7=Firmware upgraded OK, 100=error_general,   M
                                 etc.                                                       

  Action_Time       \<DTIME\>    Time stamp of action taken                                 M

  HW_Version        BSTR16       16 byte string representing hardware version               M

  SW_Version        BSTR16       16 byte string representing software version               M

  Available         INT16U       Estimated amount of curtailable load in units of 100's of  O
                                 watts                                                      

  Equipment_Type    INT8U        0=unknown,1=furnace,2=airconditioner,3=furnace/AC,4=heat   O
                                 pump                                                       

  Temperature       INT8U        Current temperature (in tenths of a degree Celsius)        O

  Setpoint_Heat     INT8U        Current setpoint temperature (in tenths of a degree        O
                                 Celsius)                                                   

  Setpoint_Cool     INT8U        Current setpoint temperature (in tenths of a degree        O
                                 Celsius)                                                   

  Mode              INT8U        Current mode (0=off, 1=heating, 2=cooling, 3=auto)         O

  InHold            INT8S        0=PCT not in Hold Mode, 1=Hold button activated            O

  Fan               INT8U        0=off, 1=on, 3=auto                                        O

  Running           INT8U        0=off, 1=Fan, 2=Compressor, 3=Both                         O

  Crypto            \<CRYPTO\>   Message integrity value                                    O
  ---------------------------------------------------------------------------------------------------

**Note:** This can be used to verify available curtailable load and
validate usage habits

**Annex G5: Transaction Sequences for Systems\
using Two-Way Communications**

(Previously referenced in Section 4.4.2)

![](media/image33.jpeg){width="3.9895833333333335in"
height="3.3333333333333335in"}

Figure 10 Two-Way 'Critical Peak Price' Event

![](media/image34.jpeg){width="5.239583333333333in"
height="4.864583333333333in"}

Figure 11 Two-Way Emergency Event

**Annex G6: IOU Use Cases for PCTs\
using Two-Way Communications**

Scenario 1 -- PCT Installation, configuration and program enrollment

1.  The home builder or customer installs the PCT and an appropriate
    communications module in a new home being constructed or qualifying
    re-model.

2.  Customer moves into a new home.

3.  Customer contacts the local utility, the customer's identity is
    confirmed and they are provided instructions to activate the
    communications aspect to the PCT.

Scenario 2 - Utility dispatches grid reliability DR program and controls
the load by communicating with the PCT

1.  CAISO (electricity grid operator)/gas distribution system operator
    notifies utility of the need to drop load for grid reliability.

2.  Utility sends communications message via Utility Communication
    Infrastructure (UCI) to PCT.

3.  PCT acknowledges receipt of signal back to Utility and curtails
    load.

```{=html}
<!-- -->
```
4.  PCT restores load to the user specified set points after an event
    has expired or a command is received via the UCI.

Scenario 3 - Utility dispatches for economics or calls a price
responsive DR program and controls the load by communicating with the
PCT

1.  Customer receives notification of event and for price response the
    appropriate pricing information

2.  Economic or price event is activated and load drop occurs.

3.  Customer chooses not to participate in economic or pricing event.

4.  PCT restores load to the user specified setpoints after an event has
    expired or a command is received via the UCI.

Scenario 4 - Customer receives utility bill and would like to confirm
the correct credit/charge was applied

1.  Customer receives the bill, with credits/penalties applied.

2.  Customer views a log of events on the thermostat.

Scenario 5 - Customer confirms that the DR event has ended, but the A/C
does not work.

1.  Customer attempts to turn on A/C but the HVAC does not respond.

2.  The PCT, after a configurable delay at the end of the DR event or a
    default time period from the start of the event, enables the
    override/restore button to reset the PCT defaults and restore normal
    operations.

3.  If step 2 fails, customer calls the utility to report problem.
    Utility confirms no event in progress, UCI or AMI indicates normal
    state, and recommends that the customer contact their thermostat
    manufacturer or HVAC installer to troubleshoot.

[^1]: E. W. Gunther, "A Strawman Reference Design For Demand Response
    Information Exchange", CEC PIER Consultants Report, October, 2004

[^2]: The specific design of such features (e.g. HOLD, OVERRIDE) is
    defined by individual vendors and not by this document.

[^3]: NEMA DC 3-2003 -
    <http://www.nema.org/redirect/redirectFile.cfm?ID=3528&user=109127&filename=/DC3.pdf>

[^4]: MultiMediaCard Specification Summary Version 3.31 March 2003 -
    <http://www.mmca.org/compliance/buy_spec/MMC-System-Summary-v3.31.pdf>

[^5]: Developed by the Radio Broadcast Data System (RBDS) Subcommittee
    of the National Radio

    Systems Committee (NRSC) -
    <ftp://ftp.rds.org.uk/pub/acrobat/rbds1998.pdf>

[^6]: Average load response during the SPP was 0.56 kW per PCT. The
    estimate here uses a range of 0.1-0.4 kW per PCT to be conservative
    and also account for temperature variations (lower temperatures
    induce smaller response).

[^7]: Assuming about 1500 MW of interruptible and AC load control
    programs.

[^8]: Load drop depends on severity of temperature setup, with maximum
    of 15% being all central AC load statewide.

[^9]: Based on estimated circuit load range of 500-2000 MW [(I'm
    checking on these numbers)]{.mark}