Utility load control management communications protocol

[0001] This application is a divisional application of U.S. application Ser. No. 11/978,933, filed Oct. 30, 2007, entitled “Utility Load Control Management Communications Protocol”, which in turn is a divisional of U.S. application Ser. No. 10/922,120, filed Aug. 19, 2004, entitled “Utility Load Control Management Communications Protocol”, which claims priority to U.S. Application Ser. No. 60/496,532, filed Aug. 20, 2003, entitled “Utility Load Control Management Communications Protocol”, each of which are herein incorporated by reference.

[0002] The invention generally relates to utility load control, and more particularly to managing utility load by communicating control commands to remotely located utility equipment.

[0003] Utility companies, specifically electricity generating and distributing utilities, must be able to generate sufficient power to serve the peak energy demand of their customers. It is well understood in the industry that the base demand is the least expensive energy to generate, while the peak demand can be the most expensive, requiring expensive peaking generators or the purchase of additional power from other utilities on a spot market. If the peak demand exceeds the capacity of the utility to generate or purchase electricity, the quality of the power provided can decline, resulting in brown-outs or load-shedding with involuntary black-outs to at least some of the utility's customers. One type of load shedding is the rolling blackout, where delivery of power to certain areas is cut off for shorter periods of time in an attempt to share the shortage over a wider base. These types of actions are necessary to maintain the quality of the power delivered to the remaining customers. Poor quality of delivered power can cause damage to expensive equipment of both the customer and the utility.

[0004] To address these problems, the utility can either increase generating capacity or reduce peak demand. Additional generating capacity is difficult and expensive to obtain, sometimes requiring the building of additional power plants. Regulatory delays and increased public opposition to the pollution and risks of new power plants has made this type of increase in capacity a long and expensive solution that is not practical for most utilities.

[0005] The less expensive and easier to implement solution to the problem is to reduce demand during peak periods through voluntary load shedding, where the power to some customers is voluntarily cut off. Voluntary load shedding has been attempted with public service pleas over the radio or television for customers to reduce their power consumption by raising the set-point on their air conditioner thermostats, closing their blinds to keep the sun out, or similar activities. For example, a residential power customer can use a set-back thermostat during the cooling season to raise the temperature of a residence during the day when the house is unoccupied, thus reducing power consumed and saving money. A set-back thermostat can be used to control an air conditioner, or a similar thermostat device used to control hot water heaters.

[0006] Other voluntary programs exist in which utility customers agree to allow the utility to reduce or eliminate power supplied during peak periods, usually with the incentive of reduced billing rates when enrolled in such programs. These programs can require action as dramatic as shutting down an entire factory, or as simple as shutting off a single residential air conditioner.

[0007] Other systems and methods of controlling energy usage and demand have also been developed. For example, U.S. Pat. No. 5,640,153 discloses an energy utilization controller and control system and method. Control data is transmitted from a remote location to a plurality of paging data receivers connected to respective energy management systems through a paging network and the energy management systems react depending on whether one or more predetermined addresses are within the control data.

[0008] U.S. Pat. No. 5,099,348 describes a display for remote receiver in a utility management system. Remote receivers in the utility management system are responsive to encoded command signals to perform utility control functions, such as removing electrical loads from the electrical distribution system or connecting a subscriber to a CATV system.

[0009] In U.S. Pat. No. 6,167,389, a control system is disclosed that varies the operation of consumer devices to minimize influx currents across a power grid. Power consuming devices are scheduled to operate in accordance with varying price tiers. The invention randomizes start up times of controlled devices so as to minimize the strain of the power grid as each one comes on line.

[0010] While the voluntary systems previously described offer some relief during peak demand periods and can be somewhat effective if a sufficient number of consumers participate, many residential customers then return to their residences and want their homes cooled down at exactly the time of the utility's peak power demand and at the time when the utility most wants to reduce demand. This is one reason the peak demand often occurs in the late afternoon, as the workday ends and utility customers return home. Another reason that the peak demand is in the late afternoon is that this can be the hottest part of the day.

[0011] Compliance with this type of voluntary load shedding has traditionally not been sufficiently effective enough to reduce demand and meet the short-term energy shortages thereby created. Further, the programs are slow to implement because of communication delays before power is cut off. For a utility to shut off 10,000 residential air conditioners would require the utility to manually or automatically send 10,000 commands to 10,000 individual customers. This process would not take place fast enough to successfully manage some peak load situations, for example when a transmission line or power generating plant goes off-line. Additionally, these systems are typically reactive and unpredictable, reducing peak demand only when there is an actual problem and making this type of load shedding extremely disruptive to each affected customer.

[0012] Therefore, a need remains in the industry for a high-speed, cost-effective, and reliable way to reduce peak power consumption through voluntary and utility-controlled load shedding.

[0013] The invention disclosed and described herein substantially addresses the above described needs by providing a load control management protocol, system, and method that quickly address many different customers, individually, in geographic groups, or in other predefined groups to control at least one or more electrical power consuming appliances. Further, the protocol, system, and method can control specific appliances and certain uses of electricity by communicating with the controllers of those appliances, for example set-back thermostats used to control air conditioners or a controller of area lighting for either indoor or outdoor lighting.

[0014] The invention facilitates communication between a utility and a thermostat to manage demand of thermostat-controlled devices. A utility can therefore reduce peak demand by pre-cooling a thermostat-controlled space before a peak demand period, for example in an early summer afternoon. The utility can remotely turn off air conditioners during the peak time, thereby shedding some load during peak demand time while the resident remains reasonably comfortable during the same period. Additional appliances such as hot water heaters or area lighting are similarly controlled to reduce power consumption during peak load periods with minimal disruption to residential or business customers. Industrial and office customers will also have machines and appliances that are controlled via wireless communication from the utility to reduce peak load demand. The invention thereby provides a way to quickly control many such appliances and machines.

[0015] The invention also provides a computer-implemented communications protocol to address a large set of customers, a set of specific appliances, selected geographic regions, or selected groups of appliances for a single or group of customers as desired in various embodiments. The invention thereby provides a load shedding protocol that is able to operatively address not only one specific customer and appliance, but is also able to address all customers or appliances in a certain geographic region with one command. For example, all customers or appliances in a certain ZIP or postal code area can be selected in one embodiment of the invention, or more than one appliance can be addressed in a single command so as to control both the air conditioner and the hot water heater, or some other combination of energy-consuming devices. The protocol also provides a plurality of available command and data message formats, enabling a utility to efficiently communicate a single command or multiple commands concatenated in a single message to a single device or group of devices.

[0016] The protocol, system, and method of the invention thereby substantially meet the aforementioned needs of the electric utility industry. The protocol, system, and method of the invention result in lower cost and more rapid control of both voluntary and involuntary load shedding schemes by controlling existing loads to adapt to changing power delivery capacity or by reducing load during peak load conditions to avoid or minimize brownouts or blackouts, among other things. The communications protocol of the invention is also easily adaptable to existing equipment and installed communication means and methods currently in use by providers of electric power.

[0017] The above summary is not intended to describe each illustrated embodiment or every implementation of the invention. The figures and the detailed description that follow more particularly exemplify these embodiments.

[0040] While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

[0041] Various embodiments of the protocol, system, and method of the invention provide control and management of a utility power-consuming load via a communications protocol administered by a master utility station. The invention can be more readily understood by reference to FIGS. 1-20, the Appendix, and the following description. The Appendix includes exemplary protocol message formats in accordance with various embodiments of the invention and is incorporated herein by reference in its entirety. While the invention is not necessarily limited to such an application, the invention will be better appreciated using a discussion of exemplary embodiments in specific contexts.

[0042] The various embodiments of the invention disclosed and described herein include a communications protocol that can, under control by a master station, communicate with a device remote controller by power line communications (PLC) methods, internet communication methods, or radio frequency (RF) communication methods in a utility and end user system. The invention can be implemented with various communication interfaces including, for example, 900 MHz FLEX one-way paging, AERIS/TELEMETRIC Analog Cellular Control Channel two-way communication, SMS Digital two-way communication, or DNP Serial compliant communications for integration with SCADA/EMS communications currently in use by electric generation utilities. The communications protocol of the invention also facilitates the control of any specified action resulting from a received communication. Such control can provide, among other actions, control of remote thermostat settings, instructions to shut down or occasionally cycle the controlled electric use, and interrogation of the controlled appliance for information relating to power consumption or other indicators of use or conditional status. Additionally, the communications protocol of the invention can control execution of any action that would improve the quality of the electric power delivered by the utility to its customers.

[0043] One embodiment of the invention provides multiple level device addressing. For example, the protocol can address a single end user appliance device using a device-level address. The protocol can also address more than one device through group-level addressing. The addressing is configurable by unique device serial number or by a combination of serial numbers, a combination of groups, or a combination including both serial numbers and groups. Multiple addresses can be provided in one addressing slot. Additionally, protocol control features are available by device serial number or by any of the addressing combinations above. The protocol also provides utility user-configurable options, including required addressing levels and logical/physical relay assignments.

[0044] Another embodiment of the protocol provides messaging options to improve communications. The protocol can operate in a dual frequency communication scheme and in one embodiment provides remote changing between programmed frequencies. Remote changing can be accomplished by the protocol with safety measures to prevent orphan system devices. Changing between programmed frequencies can also be accomplished locally or can be time triggered, for example by using a settable timer frequency or a timer reset based on specified parameters. Multiple capacitors can also be addressed on the same frequencies. Protocol messages can also include message priorities in communications that include multiple messages.

[0045] The protocol can configure device parameters, for example by device serial number or any device-level addressing combination. Another embodiment of the protocol is also compatible with and incorporates predecessor protocols. The protocol provides random number override by device, i.e. all random number commands result in zero, and can enable or disable status indicators by a device or addressing combination.

[0046] Yet another embodiment of the protocol of the invention provides increased communicative and system efficiency and functionality through a plurality of control commands and messages. The protocol includes the following functionality options in one embodiment: under-frequency control; under-voltage control; cycling control, including true cycle control and cycling control with temperature limits; temperature ramping control; device fan on/off during control; device data logging capabilities with system and device time synchronizations; selectable histories types, including time or activations; selectable propagation display times; propagation counts for testing; and device-to-device data message transmissions.

[0047] FIG. 1 illustrates a system 100 in which a utility system 110 providing electricity to an end user 120 can communicate with the electrical equipment, appliances, and thermostat devices of end user 120 to control the electrical consumption of the devices. Utility system 110 includes a central utility control center 112 in operative communication with a power generation system 114 and a power distribution system 116. Generation system 114 can include one or a plurality of power generating facilities, for example fossil fuel burning, hydroelectric, and nuclear plants, while distribution system 116 generally includes transformer-equipped routing stations and substations electrically coupling generation system 114 to a plurality of end users 110 via above- or below-ground power distribution lines 130. Utility 110 provides electricity through a power line 130 to end user 120 such that end user 120 utilizes the electricity to power, for example, an air conditioning (AC) unit 140 and a furnace 150, among other household appliances, lighting, and general electrically powered devices. AC unit 140 and furnace 150 are controlled by a thermostat 160 electrically coupled to a controller 170.

[0048] End user 120 can be a residential, business, or industrial customer. While FIG. 1 depicts end user 120 having a single thermostat 160 and controller 170, as would be typical in a central residential heating and air conditioning system, system 100 can also be implemented with end user 120 embodiments having individual device thermostats. For example, in one embodiment AC unit 140 comprises a first thermostat (not shown) for controlling unit 140, while furnace 150 comprises a second thermostat (not shown) for controlling furnace 150, wherein each the first and second thermostats includes a controller. In another embodiment, a single controller is electrically coupled to each the first and second thermostats. In yet another embodiment, only one unit 140, 150 includes or is coupled to a controller for communication with utility 110, at end user 120's discretion at installation.

[0049] In the embodiment depicted in FIG. 1, utility 110 wirelessly transmits control commands, or messages, by radio frequency (RF) via a transmitter 180 to controller 170 coupled to thermostat 160. In other embodiments, messages are transmitted via the Internet or power line control (PLC) methods to controller 170. These wired transmission modes may be necessary in some situations to reach remote end users 120 or those not capable of receiving RF messages because of localized interference or obstructions. In one exemplary embodiment, messages are sent via the Internet and routed via plain old telephone service (POTS) 190 and telephone line 192 to end user 120. Power line 130 is also available for wired message transmissions in other embodiments.

[0050] In one embodiment, the controller 170, thermostat 160, or device 140 and 150 includes a status indicator that is responsive to the control commands or messages. For example, the status indicator can comprise a light-emitting diode (LED) or a plurality of LEDs to visually indicate a message reception or implementation status, or targeted device operational status as a result of a message, to an end user in one embodiment.

[0051] Utility 110 transmits messages individually, or in combination, to a set of addresses that include geographic addresses, load-level addresses, or individual device-level addresses. The messages thus can either be transmitted to an individual address or multiple individual addresses, or can be transmitted to a group or groups of addresses. Message can also be sent to a combination of device-level and group-level addresses in one embodiment. For example, a single message can be sent to one device-level address and one group-level address, or any other combination of device-level addresses and group-level addresses.

[0052] In one embodiment, system 100 supports at least 256 unique computer-implemented communication protocol message types, for example specific load management messages, configuration messages, maintenance messages, and data messages, while also providing extendibility options to support additional functionality. Protocol messages are preferably binary byte-oriented messages but can also be converted to ASCII messages representing hex values or another message protocol format recognized by those skilled in the art. While protocol messages are preferably byte-oriented, specific messages can break individual bytes into bit-fields as necessary. Multi-byte fields are transmitted with the most significant byte first. For example, the two-byte value “2000” would be transmitted in two bytes 07,D0. The length of any message is determined from the data in the message itself. It is thus not necessary to continue parsing a message until no additional data is found, thereby enabling multiple messages to be concatenated, forming a single variable length message.

[0053] One embodiment of the computer-implemented protocol of the invention is designed to provide nine levels of addressing: eight group-level and one device-level. In this embodiment, six geographical address levels are dedicated to broadcasting to end user devices based upon geography, while two address levels are dedicated to load-level addressing. Group-level addresses can be sent together to narrow the target area. A device-level address is also available for communicating with an individual target device. In one embodiment, the individual target device is identified by its unique serial number.

[0054] Several values have special meaning in one embodiment of the protocol. For example, 0xff, 0xffff, and 0xffffff, for one-, two-, and three-byte address values, respectively, are universal “all call” addresses to which any end user device with a valid non-zero address at this addressing level will respond if all other addressing criteria are met. FIG. 2 includes the various address responses and the addresses used in the message and in the device. If an asterisk (*) is shown, the device will respond to the message. Note also that a feeder, a bit-wise address level, will respond if the message address and the device address have any set bits in common, i.e. the bit-wise and operation result is non-zero.

[0055] When a geographical group address is used, any combination of the levels can be collectively sent in a message, allowing maximum flexibility for targeting field devices. A service provider address (SPID) is a two-byte address level sent with all group address messages and used to identify the service provider, or owner utility 110, in case of any communications crosstalk or on a shared communications network. Valid values are 1 to 65,534 in one embodiment. A GEO address is a two-byte address level geography code intended to identify a target geographical area as determined by utility 110, where valid values are 1 to 65,534. A substation address is a two-byte address level intended to identify the utility substation on which the target end user equipment is located. Valid values are 1 to 65,534. A feeder address is a two-byte address level intended to identify the utility feeder that feeds the load and is normally, although not exclusively, combined with the substation address. Each bit in the feeder address represents a feeder and therefore supports up to sixteen feeders, allowing a set number of feeders to be targeted with a single message. Feeders are numbered one to sixteen from least significant bit to most significant bit. A zip address is a three-byte address level that can be used as a postal ZIP code and can also be used for any other addressing options. Valid values are 1 to 16,777,214. A user-defined address, or UDA, is a two-byte address level intended to be user definable for any other desired addressing options and has valid values of 1 to 65,534.

[0056] When a load-level group address is used, any combination of the levels can be collectively sent in the message, including geographical addresses. This provides maximum flexibility for targeting end user devices. One load-level group address is a program address. This one-byte address level is used to target program loads. End user devices that control multiple loads will contain a separate program address for each load. Valid values are 1 to 254. Another load-level group is a splinter address, a one-byte address level used to target a subset of a program load address. End user devices that control multiple loads can contain a separate splinter address for each load device. Valid splinter address values are 1 to 254 and are normally sent with a program address, although the protocol does not prevent splinter address values from being sent alone.

[0057] Embodiments of the protocol of the invention also support individual end user device addressing by device serial number. The protocol is configured such that an individually addressed message applies to a single device and does not include any group addressing. This four-byte address level supports up to about 4,294,967,295 unique devices in one embodiment.

[0058] In addition to supporting group- and device-level addressing, embodiments of the protocol of the invention also support four primary categories of load management control commands. These categories include timed control messages, cycling control messages, restore control messages, and thermostat set-point control messages.

[0059] Timed control messages support a single time duration in which the load is to be controlled. Timed control messages can also include other parameters.

[0060] Cycling control messages cycle the load on and off for a specified time duration and for a defined number of periods. A percentage is also specified to calculate the off time.

[0061] A restore control message cancels a previous load control command and restores the targeted load. These messages can also include a random start time.

[0062] A thermostat set-point control message is used to set back or pre-operate, i.e. cool or heat, a smart thermostat end user device. A thermostat set-point control message includes data regarding the operational setting change.

[0063] The protocol of the invention further supports other messages, including distribution automation messages, maintenance messages, and data messages. A specialized capacitor control command message operates a relay in a capacitor control device. This message can also override local operating parameters or perform other specific capacitor bank controller functions. The protocol supports a variety of maintenance messages, which can include configuration commands, test commands, out of service commands, and history reset commands, among other maintenance message commands. Communication of data messages enables a block of data to be transferred to a selected device port. Data message commands can also support a reply form a two-way end user device.

[0064] The messages identified above will be described below in further detail. Each message generally comprises five elements:

• • [0065] Message start indicator
  • [0066] Message addressing
  • [0067] Message type
  • [0068] Variable fields (message type dependent)
  • [0069] Message terminator

[0070] A start of message indicator marks the beginning of a message and can vary in protocol embodiments, based upon the communication technology used. For example, in a FLEX paging network, a message will begin with a single ASCII start of message character. Referring to FIG. 3, message addressing 300 includes a one-byte address-level indicator 310, followed by the addressing 320. The message address level byte 310 indicates the addressing that will be included in the message 300. A zero value indicates that the message is a unique serial number. Each other bit in the message represents an address level that has been included in the message. In one embodiment of the protocol of the invention, there are two categories of group addresses: geographical and load. Addressing 320 that is included in the message, based upon the bits that are set, will follow address level byte 310. Addresses 320 will be ordered according to the most significant bit position, i.e. service provider identifier first. This results in addressing portion 320 of message 300 having a variable length based upon the included addresses and their byte size.

[0071] Referring to FIG. 4, a message type byte 410 will follow address level byte 310 and variable length addressing 320. Message type byte 410 indicates the type of message that has been sent. One embodiment of the protocol of the invention supports at least 256 unique message types. The variable length messages 420 follow message type byte 410. The protocol can support multiple message types and associated data in a single message. If the byte following the variable data in a message is not a message terminator, the protocol will interpret the byte as an additional message type.

[0072] The variable length messages 420 can include various command messages and other related information. Message 420 can include a synchronization message used to keep end user devices locked onto a given frequency or paging company, or a time synchronization message used to keep devices having internal clocks in synch with utility control center 112. Message 420 can also comprise a priority command message to set the priority of all following commands that are concatenated to this command. In one embodiment, “0” is the highest priority and “3” is the lowest, although these values can vary depending upon the application. Message 420 can further comprise a signal test message used to test signal reception of devices in the field.

[0073] Referring to FIG. 5, variable length message 420 can comprise a timed load control message 500 used to control an end user device load for a specified amount of time. In one embodiment, message 500 includes a shed time 530, a ramp-in time 540 and a ramp-out time 550, and a delay time 560 after the message control flags 520.

[0074] FIG. 6 depicts a restore load control message 600. Message 600 is used to cancel control of a load in a device and can also include a ramp-out time 610 and a delay time 620.

[0075] FIG. 7 illustrates one embodiment of a cycle load control message 700. Message 700 is used to control a load in an end user device by cycling the load off for some cycle period 720, or percentage of time of a specified number of minutes 710. Message 700 can also include a cycle count 730, the number of periods 710 for which to operate before stopping. A delay time 620 is optional but also available.

[0076] An extended cycle load control message can be used to control a load in a device by cycling the load off for a percentage of time of a specified number of minutes. FIG. 8 depicts one embodiment of an extended cycle load control message 800. After the message addressing 300 and message type 410, message 800 includes control flags 810 and 820. Control flags 810 can be used to indicate whether the device is in a heating or cooling mode, whether degree values will be expressed in Celsius units or Fahrenheit units, and other message indicators. Control flags 820 can include bits to prevent a ramp-in during start, limit and maximum temperature changes per hour, and particular load numbers to control, among other message indicators. Cycle percentage 710 communicates a percentage of off-time in a given period 720, where a zero percentage value terminates the current cycle control at the end of the current cycle period. Period 720 is expressed in minutes and in one embodiment supports periods of one to about 255 minutes. Cycle count 730 is the number of periods to operate before stopping. Message 800 also supports a two-byte delay start time in one embodiment, expressed in minutes. A control temperature value 830 is optional and controls the temperature during a cycle on time. A limit temperature 840 can be used to specify a maximum or minimum temperature. A fall back A % 850 is an optional new cycle percentage for use if the space temperature limit temperature is exceeded. A maximum degrees per hour message 860 is also optional and can specify a maximum heating or cooling rate, i.e. a maximum number of degrees a space temperature can change in an hour. A fall back B % message 870 is an optional new cycle percentage to be used if the space temperature is changing too quickly in a current cycle.

[0077] In one embodiment, if any thermostat command is received while another is being implemented, the new command will override the previous command when the new command's delay time is complete. This enables a restore command to be sent to terminate any thermostat control message.

[0078] FIG. 9A is a diagram of an implementation over time of a thermostat set-point control message. FIG. 9B depicts one embodiment of a thermostat set-point control message 900. Message 900 is used to modify the temperature set-point of a “smart” thermostat. As shown in FIG. 9A, message 900 includes commands to implement change deltas offset from a current temperature, or absolute temperatures, ramp times, duration minutes, and optional upper and lower limits. Message 900 can also implement a start delay A. A pre-cooling period BC and a control period DEF are also shown, although message 900 can also apply to a pre-heating period followed by a lowered temperature set-point during control period DEF. Message 900 as depicted in FIG. 9B gradually pre-cools a temperature space and then gradually raises the space temperature, evenly distributing the demand relief across control period DEF. In one embodiment the temperature change can be adjusted to peak during the hour in which market rates are highest. The soft restore serves to alleviate a peak that would otherwise occur if all of the thermostats in a region were restored simultaneously. This method of control essentially prepays the payback that occurs at the end of all air conditioner control, thus increasing the available demand relief during target hours while maintaining customer comfort at an acceptable level.

[0079] At time t₀, command message 900 is received by the thermostat and controller (refer to FIG. 1). Delay time A, plus a random offset, can be implemented before message 900 is implemented at t_A. Time period B, from t_A to t_B, is a ramped control period, wherein the set-point changes in one-degree increments to achieve a specified set-point, S_B, or set-point delta, Δ_B, over a specified time period, T_B. Thus, the temperature set-point S_B at time t_B is defined as:
S_B=S₀+Δ_B
For example, if Δ_B=3 degrees and T_B=90 minutes, the temperature set-point S_B would be decreased by one degree at t_A, by another degree at t_A+30, and by a further degree at t_A+60. If absolute temperatures are specified in message 900, the formula is defined as:
Δ_B=S_B−S₀

[0080] Time segment C, from t_B to t_c, shows a plateau control period, wherein the setpoint S_B is maintained for a specified time, T_c, at the set-point S_B programmed in time segment B. Time segment D, from t_C to t_D, shows a ramped control period, wherein set-point S_B changes in one-degree increments to achieve a specified set-point delta, Δ_D, over a specified time period T_D. Because Δ_D is referenced to S_B, the temperature set-point S_D at t_D is defined as:
S_D=S_B+Δ_D=S₀+Δ_B+Δ_D
Time segment E, from t_D to t_E, shows a plateau control period, wherein the set-point is maintained for a specified time, T_E, at the set-point S_D programmed in time segment D. Time segment F, from t_E to t_F, shows a ramped control period in which the set-point changes in one-degree increments to achieve a specified set-point delta, Δ_F, over a specified time period, T_F. Δ_F is referenced to S_D, thus the temperature set-point S_F at t_F is defined by the following:
S_F=S_D+Δ_F=S₀+Δ_B+Δ_D+Δ_F
Set-point S_F will generally be the same as the original set-point S₀:
Δ_B+Δ_D+Δ_F=0
Regardless, all control of the thermostat will cease when this ramp control period finishes in one embodiment unless a maintain control bit is set in message 900.

[0081] When implementing a ramped temperature control of Δ degrees over time period T, the thermostat will typically be adjustable in discrete steps, for example one degree each. The first step will be taken at the start of the period and the last step, if there is more than one step, will be taken at the end of the period T. Additional steps will be taken at equal intervals of T/(Δ−1) over the period T. Because the last step is not taken until the end of the period, a plateau control period is implemented in one embodiment to allow the thermostat to bring the room to the new set-point for the ramped temperature control to be effective.

[0082] As shown in FIG. 9B, message 900 comprises message addressing 300, message type 410, and control flag 810 and 820 bytes as previously described with reference to other command messages. Control flags 810 and 820 can be used to specify temperature units of measure, inclusion of minimum or maximum temperature values, heating or cooling modes, and other message indicators. Extended control flags 910 are optional and can be used to indicate which particular load or loads to target for control. Min byte 920 and max byte 930 are also optional bytes of message 900 and can be used to set a minimum and maximum temperature in degrees. Any calculated set-points that exceed the minimum and/or maximum temperatures specified by min 920 and max 930 will be set to the specified temperatures, respectively. In one embodiment, min 920 and max 930 bytes are only present in message 900 when corresponding bits in control flags 810 and 820 are present.

[0083] The remaining bytes shown in message 900 are also optional. With reference to FIG. 9A and the previous corresponding description, T_R sets a random offset time in minutes. T_A sets a delay time in minutes. T_B is used to set a ramp time in minutes, Δ_B indicates the set-point delta relative to the uncontrolled set-point in degrees, and S_B sets an absolute set-point in degrees. T_c can specify a plateau time in minutes during which the set-point S_B is maintained. T_D indicates a ramp time in minutes, Δ_D represents the set-point delta relative to S_B in degrees, and S_D is an absolute set-point in degrees. T_E expresses a plateau time in minutes during which set-point S_D is maintained. T_F sets a ramp time in minutes, Δ_F indicates a set-point delta relative to S_D in degrees, and S_F sets an absolute set-point in degrees.

[0084] FIG. 10 shows an exemplary thermostat set state command message 1000. Message 1000 is designed to permit a thermostat owner to configure the thermostat's state. A thermostat owner could be a homeowner, business owner, or property manager, for example. In one embodiment, message 1000 mimics a corresponding thermostat front face control panel and can be overridden by the thermostat's control panel if desired. If message 1000 is received while any other control is in place, message 1000 will be preempted and ignored.

[0085] As in previous messages described above, message 1000 begins with message addressing 300, message type 410, and control flag 810 and 820 bytes. Control flag high byte 810 can be used to indicate whether a timeout 1010 is included, whether the set state command is temporary, and whether a heating or cooling mode is in use, among other indicators. Control flag low byte 820 can indicate whether timeout 1010 is expressed in hours or default minutes, whether a delay time 620 is included is in message 1000, and whether Celsius or Fahrenheit units are used, among other indicators. Optional timeout 1010 can be expressed in minutes or hours. At the end of the period specified in timeout 1010, the thermostat is restored to its default programmed state. Set-point temperature 1020 is also optional, as is a delay time 620.

[0086] Variable length message 420 can also comprise a thermostat price tier command message 1100, as shown in FIG. 11. Message 1100 sets a thermostat's price tier level 1110 to provide an indication of current cost of usage to a homeowner. Price tier 1110's valid range in one embodiment is from 0 to 4, wherein a message including a price tier 1110 of 0 will disable the price tier display indication.

[0087] FIG. 12 depicts a configuration message 1200, another variable length message 420 format. Message 1200 is used to send configuration data to field devices. In one embodiment, message 1200 includes customary message addressing 300 and message type 410 bytes as described with reference to other available variable length messages 420, followed by a configuration number 1210 in the first data byte to indicate what to change. Configuration number 1210 is followed by a data length indicator byte 1220 and data 1230. In one embodiment, message 1210 can include up to about 255 bytes of data 1230.

[0088] FIG. 13 illustrates one embodiment of a maintenance function message 1300. Maintenance function message 1300 can be used to perform internal maintenance in a field device, for example resetting a history counter, freezing a history counter, or similar functions. Message 1300 includes a function identifier 1310 and option bytes 1320. Function identifier 1310 indicates what maintenance function work will be performed. Option bytes 1320 provide the function work instruction. Option bytes 1320 can include load number bits such that a particular load or group of loads can be targeted with message 1300.

[0089] Variable length message 420 can also comprise a permanent service change message 1400, as shown in FIG. 14. Permanent service change messages 1400 can be used to deactivate or activate a field device or load from operation. Message 1400 thereby permits customers to be removed from a program without service personnel having to physically visit the remote site. In one embodiment, message 1400 can target a specific load or an entire unit. When an entire unit is out of service, the unit's lights will be turned off and the unit will respond only to a permanent service activate command message 1300 (refer to FIG. 13 and the corresponding description). Message 1400 includes standard message addressing 300 and message type 410 bytes followed by a service action byte 1410. Service action byte 1410 includes bits set to specify an activate or deactivate command and bits to specify a particular load or device to target.

[0090] A temporary service change message 1500 is shown in FIG. 15. Message 1500 is used to temporarily deactivate a field device from operation for a specified number of hours, allowing customers to be removed from a program for a short period of time without having to send service personnel to the remote device. Message 1500 targets an entire unit. Message 1500 includes message addressing 300 and message type 410 bytes, followed by a service action byte 1410 and hour bytes 1510. A temporary service change message 1500 sent with 0 hours will keep the device permanently out of service, although the device's indicator lights could remain active and the device will continue to respond to configuration messages 1200 and maintenance messages 1300. Message 1500 also includes a flag byte 1410 that can be used to indicate a cancel, lights, and cold load pickup action. Hour bytes 1510 are used to specify the number of hours for the temporary service change. For example, hour bytes 1510 of “0x0048” would deactivate a device for 72 hours.

[0091] A data message 1600 as shown in FIG. 16 can be used to send a block of data to a field device. Data message 1600 includes a configuration byte 1610 to specify the format of the data being sent, for example binary or hex, and a data message length byte 1620. Data message block 1630 can include up to about 255 bytes of data in one embodiment. Message 1600 can also specify a port number for the data to be sent to in the device, where a “0” would send the data to the default port. Data within data block 1630 is sent in most significant bit (MSB) order.

[0092] A capacitor command and control message 1700 as shown in FIG. 17 can be used to control information to capacitor bank controller (CBC) field devices. Command message 1700 can, for example, open or close a device, or enable or disable a local over-voltage/under-voltage specification. Following message addressing 300 and message type 410 bytes, message 1700 includes an action byte 1710 and sub-action byte 1720 and optional data 1730. Action byte 1710 can comprise a control byte followed by a particular sub-action 1720, for example an open, close, enable, or disable action command. Action byte 1710 can also comprise a configuration byte followed by a one- or two-byte sub-action 1720. Various sub-actions 1720 are available and can include, for example, a control relay time, an enable or disable CBC function, a brown out level action, a control limit, and an over-voltage/under-voltage calculation time, among a plurality of other available sub-actions 1720.

[0093] Utility 110 can also request a reply from a field device using a request data command message 1800. In one embodiment, data message 1800 comprises a start indicator 1802, an address level byte 1804, a service provider identification byte 1806, and message type byte 410. Data message 1800 also comprises a request identification byte 1808 that identifies the particular request and is returned with the device's reply to message 1800. Length of request descriptor 1810 specifies the number of bytes that follow to describe the requested data. The request format will be unique to different data requests and can include a data length requested. Request byte 1812 indicates what data is requested for return from the device and can include configuration data, an EEPROM data block, a meter data request, and a CBC data request. Subsequent request bytes 1814 up to a final request byte n 1816 will depend on request byte 1812. A schedule identification 1818 precedes the remaining bits, wherein the remaining bits are ignored if schedule identification 1818 is omitted. Period byte 1820 specifies how often to send a reply, for example an immediate reply and then every thirty minutes or at the start or end of the first period. Offset 1822 is used to specify when the first period starts relative to a real time clock. Offset 1822 can also be used to set a period start at receipt of message 1800 or at a random offset within period 1820. Timeout 1824 indicates a number of replies to send, wherein “00” indicates infinite replies until canceled. Terminator 1826 indicates the end of message 1800.

[0094] One embodiment of a data reply message 1900 is shown in FIG. 19 and is used to return data requested in a data request message 1800. Data message 1900 identifies the data and the original data request. Address level 1804 follows start indicator 1802 and is included for format compatibility. An optional 32-bit Hex serial number of the device sending message 1900 can be included as address serial bytes 1902. The request ID 1808 from the original data request message 1800 is included after message type byte 410 and can also indicate an unsolicited reply. Length of request descriptor 1810 indicates the number of bytes that follow to describe the requested data. The request format will be unique to different data requests and can include a data length requested. Descriptor 1810 can be “00” for solicited replies in which request identification 1808 is sufficient to identify the requested data type. Request bytes 1812, 1814, and 1816 indicate what is returned and request length 1904 indicates the length of the data in binary bytes. The requested or unsolicited data follows in data block 1906 and is followed by message terminator 1826.

[0095] Referring also to FIG. 1, FIG. 20 is a flow chart that illustrates one embodiment of a method 2000 of communicating between utility 110 and end user 120 devices, such as AC unit 140 and furnace unit 150, using the computer-implemented protocol of the invention. In this example embodiment, a protocol command message in accordance with one of the command message formats described herein above is formulated at a utility control center 112 computer at step 2002. In one embodiment, message formulation is performed at the utility end using software implementing the communication protocol and message compositions and formats described above. At decision step 2004 the command message target is analyzed. If the command message is targeting a single device unit, serial number addressing is inserted into the command message at step 2006. Next, at step 2008, the desired command action is inserted into the command message. Additional command actions for the same target(s) can be inserted at step 2010, resulting in variable length command messages that are transmitted to the desired controller 170, thermostat 160, and device 140 and 150 targets at step 2012. As previously described, the command messages can be sent from utility 110 to end user 120 or multiple end users or groups in RF communications from transmitter 180, via POTS 190 and 192, or via power line 130 wired transmissions.

[0096] The computer-implemented communication protocol of the invention facilitates communication with a single targeted unit or with a plurality of targeted units that are geographically dispersed. The geographically dispersed units that are targeted can be a defined geographical area group or can be particular targets defined by their load addresses. A utility can therefore select a group based upon a peaking load condition in a limited geographic area to be targeted for load reduction to prevent the peak condition from affecting a wider geographic area. A particular set of high consumption devices can also be targeted as a group, for example air conditioning units known to consume more power in high temperature conditions. A utility can also define a group based upon end user participation levels. For example, a first group of users could be targeted first for load reduction in exchange for the lowest overall power rate offered under a particular plan. A second group could be targeted next as needed in exchange for an overall power rate slightly higher than the first group's but yet lower than the standard rate. Other groups can also be defined as desired.

[0097] Returning to step 2004, if the command message of step 2002 is targeting more than an individual unit, then at step 2014 it is determined whether the target is a geographical area. If yes, then the geographical area address(es) are inserted at step 2016. If particular load addresses are also being targeted (step 2018) or if the load addresses are the desired targets, those addresses are inserted at step 2020. The desired command action(s) are then inserted into the command message at steps 2008 and 2010 and the command message is transmitted. Upon receipt of the command message at controller 170, the command actions are implemented according to the criteria specified in the message at the targeted devices.

[0098] In one embodiment, the protocol, system, and method of the invention are compatible with existing communications protocols while still providing the versatile addressing and command messaging options of the invention. Previous-generation communication protocols and predecessor messaging techniques can thereby be incorporated into new systems or expanded and updated by the invention to provide additional cost-savings and versatility.

[0099] The invention thereby provides a protocol, system, and method for managing utility loads and communicating control commands to remotely located power-consuming devices. The invention may be embodied in other specific forms without departing from the spirit of the essential attributes thereof; therefore the illustrated embodiments should be considered in all respects as illustrative and not restrictive, reference being made to the appended claims rather than to the foregoing description to indicate the scope of the invention.