method and system for reducing electrical load in a building automation facility and computer readab

专利摘要:
METHOD AND SYSTEM FOR REDUCING ELECTRICAL CHARGE IN A BUILDING AUTOMATION FACILITY AND COMPUTER-READABLE MEDIUM WITH INSTRUCTIONS TO CONTROL BUILDING AUTOMATION. The present invention relates to a system and method for reducing an electrical load in a facility with a building automation system (22) which includes first receiving information for a demand response event from a demand response server automated (14) on an automated demand response client (18). Upon receipt of a new demand-response event, the system determines a plurality of building automation system devices to be controlled during the demand-response event. Next, the system prepares a schedule of control actions for the plurality of devices during the demand response event. The system then sends control messages to the building automation system to perform the control actions for the plurality of devices according to the control action schedule for the demand response event.
公开号:BR112013032179B1
申请号:R112013032179-2
申请日:2012-06-08
公开日:2021-05-04
发明作者:Raphael Imhof；Pornsak Songkakul；Michael J. Marchi；Thomas Rule；Paula Hiller；Florian Ersch
申请人:Siemens Industry, Inc.；Siemens Corporation；
IPC主号:

专利说明:

FIELD OF THE INVENTION
[0001] This application relates to the field of energy consumption management, and particularly to the automated handling of demand response requests from energy suppliers. BACKGROUND
[0002] Power distribution companies, which include electricity producers are often in a situation where it would be advantageous to reduce the demand for electricity ("demand kW") by customers ("end users"). In particular, at times of peak demand it is advantageous to reduce the total energy consumption and thus reduce the weight on the electric power generators that supply power to the electric power grid. When total power consumption is sufficiently reduced during peak demand hours, the electrical power network can be stabilized so that electrical power can be safely supplied to end users, thereby avoiding partial cuts or possibly blackouts.
[0003] In order to limit power consumption during hours of peak demand, electricity providers have traditionally increased the price of electricity during hours when it is known that electricity demand will be high. The hope is that the increased price of electricity during these high demand hours will cause end users to limit electricity consumption, and thus avoid overloading the electricity grid during peak demand hours. However, electricity providers have found that merely raising the price of electricity during peak hours is often insufficient to avoid excessive demand. Thus, additional systems and initiatives have been developed to encourage end users to reduce electrical loads during hours of high demand.
[0004] Demand Response ("RD") agreements have been used by energy suppliers to request electrical load reduction. With Demand Response agreements, the electricity supplier contacts certain end users during certain Demand Response events that are associated with peak demand hours. In exchange for reducing the load during these Demand Response events, the end user receives certain price reductions. Demand Response agreements benefit the electricity supplier by reducing energy consumption during peak hours, and also benefit the end user through energy price reductions.
[0005] Communications from the electricity supplier to the end user indicating that a Demand Response event is expected to occur in the near future were initially in the form of telephone calls or emails. Upon receiving these phone calls or emails, the end user must take appropriate action to reduce energy consumption under the Demand Response agreement. For example, during a hot weather DR event, a building operator may temporarily increase the thermostat temperature, dim the lights, increase the refrigerator temperature, or take another action to reduce energy consumption during the response event. demand. This action typically occurred manually by an individual making the appropriate adjustments to various building control systems.
[0006] With more modern systems, Demand Response events are typically communicated to the end user automatically by computers using a client-server model. In particular, an RD server at the electricity supplier communicates Demand Response events to an RD client at the end user's location. The RD Server can send data that concerns the Demand Response event to the RD Client, or the RD Client can poll the RD Server for data that concerns the Demand Response events. There are several protocols for communicating RD signals between the RD server and the RD client. One such protocol is the OpenADR (Open Automated Demand Response Communication Specification Version 1.0) protocol developed by Lawrence Berkeley National Lab and Akuacom. OpenADR has been adopted by California energy providers and could become a national standard for communicating Demand Response signals. Under current Demand Response systems, when an RD client receives an RD event message that provides information regarding a Demand Response event from an RD server, the RD event message is passed to an individual or system responsible for taking corresponding load reduction actions.
[0007] Although past Demand Response systems have been useful in reducing energy consumption during periods of high demand, it should be advantageous to further improve these systems. In particular, it should be advantageous to provide a Demand Response system that is automated and efficiently reduces electrical power consumption in a facility during various DR events based on user-configured strategies for responding to DR messages. SUMMARY
[0008] According to an embodiment of the description, a method is provided to reduce an electrical load in an installation with a building automation system. The method includes receiving information for a demand response event and then determining a plurality of building automation system devices to be controlled during the demand response event. The method further includes preparing a schedule of control actions for the plurality of devices during the demand response event. Additionally, the method includes sending control messages to the building automation system to perform the control actions for the plurality of devices in accordance with the control action schedule for the demand response event.
[0009] In at least one embodiment, the method further includes reviewing the scheduling of control actions to determine if there is a scheduling conflict for control actions related to one of the plurality of devices. If the conflict exists in the schedule, the method additionally comprises resolving the conflict in the schedule based on an execution priority order for the control action, where the execution priority order is related to a demand response control period for the control action. Demand response control periods can include a demand response control period that occurs during the demand response event, a demand response control period that occurs before the demand response event, or a period of demand-response control that occurs after the demand-response event.
[00010] In at least one embodiment of the description, a system for reducing the electrical charge in a building is disclosed. The system includes a building automation system (SAP) that has a plurality of field panels configured to deliver control instructions to a plurality of devices in the building. The system also comprises an automated demand-response client configured to receive a demand-response event message from an automated demand-response server. The automated demand response client includes a scheduler component and an SAP communications component. The scheduler component is configured to prepare a schedule of control actions for the plurality of devices during the demand response event. The SAP communications component is configured to distribute the control actions to the plurality of devices to the plurality of SAP field panels according to the schedule.
[00011] In at least one embodiment, the system includes a graphical user interface configured to display information relating to the actual energy consumption of the facility during the demand response event. The graphical user interface can also be configured to display a graph showing demand response events and a plurality of demand response modes associated with demand response events over a selected period of time.
[00012] In at least one further embodiment of the description, a computer readable medium contains instructions for controlling a computer system to generate instructions for controlling a building automation system. The computer-readable medium includes instructions for controlling the computer system by having the computer system receive the information for a demand-response event from an automated demand-response server. The instructions also cause the computer system to determine a plurality of devices in the building automation system to be controlled during the demand-response event and prepare a schedule of control actions for the plurality of devices during the demand-response event. Additionally, the instructions cause the computer system to send control messages to the building automation system to perform the control actions for the plurality of devices in accordance with the control action schedule for the demand response event.
[00013] The systems, methods, features and advantages of the present invention described above, as well as others, will become more apparent to individuals of ordinary skill in the art by reference to the following detailed description and attached drawings. While it would be desirable to provide an automated Demand Response system that provides one or more of these or other advantageous features, the teachings disclosed in this document extend to those modalities that fall within the scope of the attached embodiments, regardless of whether they obtain one or more of the advantages mentioned above. BRIEF DESCRIPTION OF THE DRAWINGS
[00014] The components in the figures are not necessarily to scale, instead emphasis is placed on illustrating the principles of the invention. In the figures, like reference numerals designate corresponding parts throughout the different views.
[00015] FIGURE 1 shows a block diagram of an exemplary automated demand response system that includes an automated demand response server (also referred to in this document as a "Demand Response Automation Server" or SARD) and a plurality of automated demand-response clients; FIGURE 2 shows a block diagram of an electrical network that connects an electricity distribution company operating the automated demand response server of FIGURE 1 to a plurality of end users operating automated demand response clients; FIGURE 3 shows a block diagram of the automated demand response server of FIGURE 1 which includes a SARD application held in memory; FIGURE 4 shows a block diagram of one of the automated demand response clients of FIGURE 1 in communication with a building automation system, where the automated demand response client includes an RDA application client held in memory for execution by a processor; FIGURE 5 shows a functional block diagram of the RDA application client architecture of FIGURE 4 in association with a field panel of a building automation system and the SARD application; FIGURE 6 shows an illustration of an exemplary building that includes a building control system configured to receive communications from the RDA application client of FIGURE 5; FIGURE 7 shows an exemplary worksheet of a strategy for responding to various demand-response events using the automated demand-response client of FIGURE 5; FIGURE 8 shows a graphical user interface screen generated by the RDA application client of FIGURE 5, where the screen is configured to enable an end user and identify points from a building automation system to the RDA application client; FIGURE 9A shows a graphical user interface screen generated by the RDA application client of FIGURE 5, where the screen is configured to allow an end user to configure building automation system points to control during various modes of an event. RD; FIGURE 9B shows another graphical user interface screen generated by the RDA application client similar to that of FIGURE 9A and configured by the RDA application client to allow an end user to configure building automation system points to control for various periods of an RD event, which includes periods before and after a mode of an RD event; FIGURE 9C shows yet another graphical user interface screen generated by the RDA application client similar to that of FIGURE 9A and configured by the RDA application client to allow an end user to configure building automation system points to control over multiples. periods of an DR event, which includes periods before and after an RD event; FIGURE 10 shows a graphical user interface screen generated by the RDA application client of FIGURE 5, where the screen is configured to allow an end user to enter data to allow the RDA application client to establish communications with the SARD of the power distribution company; FIGURE 11A shows an illustration of an example demand response event processed by the RDA application client in accordance with the present invention, where the demand response event specifies multiple RD commands and the RDA client identifies potentially control actions conflicting for a point to be controlled in response to RD commands; FIGURE 11B shows the exemplary demand response event of FIGURE 11A as a step function that reflects the resolution by the RDA application client in accordance with the present invention of conflicting control actions; FIGURE 12 shows an execution order priorities graph for resolving different RD modes conflict and different RD events by the RDA application client in FIGURE 5; FIGURES 13A to 13D show flowcharts for various processes performed by the RDA application client of FIGURE 5, which include a scheduling routing in FIGURES 13B and 13C and a scheduling conflict resolution screen in FIGURE 13D; FIGURE 14 shows a graphical user interface screen generated by the RDA application client of FIGURE 5, where the screen provides a graph of the history of demand response events received by the automated demand response client of FIGURE 5, which includes information from past, current and future DR events; FIGURE 15 shows a graphical user interface screen generated by the RDA application client of FIGURE 5, the screen providing a record of actions taken by the automated demand response client of FIGURE 5; and FIGURE 16 shows a graphical user interface screen that may be developed to supplement the RDA application client of FIGURE 5, where the screen provides a report of power consumption during a demand reduction event. DESCRIPTION
[00016] Referring to FIGURE 1, there is shown a high-level block diagram of an exemplary automated demand response system 10. System 10 includes a demand response automation server computer ("SARD" or "Sard Server" RD”) 14 located at the site of an electricity distribution or aggregation company 12, and a plurality of automated demand-response client computers ("RDA customers") 18 located at various customer facilities 16. Each RDA customer 18 is coupled to a building automation system (SAP) 22 that is configured to control various building environments and safety devices, such as lights, thermostats in HAVC systems, alarm systems, and fire alarm systems at the customer site 16 The SARD 14 and the RDA client 18 are each equipped with communication capabilities and can be communicatively coupled to a communications network 20, such as the Internet, thereby enabling communications flow between the SARD 14 and the RDA 18 clients.
[00017] Although SARD 14 or RDA 16 clients may each comprise a complete personal computer, it will be understood that the system and method can also be used in connection with mobile devices capable of wirelessly exchanging data with a server over a network just like the Internet. In either case, the RD Server 14 and the RDA Client 18 are configured for the power distribution company and each end user to meet a Demand Response communication protocol standard, such as OpenADR. Additionally, although the SARD 14 and RDA 18 customers are shown in the FIGURE 1 mode as being located at the location of the utility company 12 or customer premises 16, it will be recognized that in other embodiments, the SARD 14 and customers of RDA 18 can be located at remote locations from the location of the utility company 12 and customer premises 16. In these arrangements, the SARD 14 and RDA 18 clients are typically configured to communicate with other computers or devices. at the electricity distribution company site 12 or at customer premises 16 through communications networks 20.
[00018] Referring now to FIGURE 2, in an exemplary modality, an electric power distribution company 12, which is an operator or affiliate of the operator of SARD 14, can supply electric power over a power network 24 to 16A end users , 16B, 16C, which are customers, and consume electrical energy supplied over the grid 30 by the power distribution company 12. At least part of the electrical energy consumed by each end user 16 is used to power devices controlled by the user's SAP 22 system end 16. Supplementary power sources 26 can also be connected to the power grid 24. These supplementary power sources 26 can be controlled, for example, by end users 16 to generate and supply supplementary electrical power to the power grid 24.
[00019] End users 16 are typically commercial or industrial entities such as shopping centers or factories that have a kW demand that is large enough to participate in traditional demand reduction programs. End users 16 can also be an aggregation of residential or commercial units (eg an apartment complex or commercial units in a shopping center) that have a relatively large aggregate demand of KW. However, in other modalities, it will be assessed that end users 16 may even be residential units that have SAP systems 22 that automate the control of various environmental control devices in the home or other residence. These SAP systems are becoming more common in homes. Therefore, because the Demand Response 10 system is fully automated, as explained in further detail below, a homeowner or other residential customer could easily add an RDA 18 customer to the home and participate in the Demand Response 10 system as explained in this document. SARD
[00020] Referring now to FIGURE 3, in an exemplary embodiment, the SARD 14 may include a processor 30, a memory 32, a communications network interface device 38, I/O ports 39, and other components typically present. on a general purpose computer. Memory 32 stores information accessible by processor 30, which includes data 36 that can be retrieved, manipulated, or stored by processor 30, and a SARD application 34 configured to process RD event information and generate RD messages. Memory 32 can be of any type capable of storing information accessible by the processor, such as a hard disk, memory card, ROM, RAM, DVD, CD-ROM, read-only memories, or other computer-readable medium. Processor 30 can be any well-known processor, such as processors from Intel Corporation or AMD. Alternatively, processor 30 can be implemented in combination with the application of SARD 34 and/or other logic in a dedicated controller such as an Application Specific Integrated Circuit ("ASIC"). Processor 30 is configured to retrieve, store or modify data in accordance with the application of SARD 34 in memory 32. Data 36 can be stored in computer records, in a relational database as a table containing a plurality of different fields. and records, XML documents, or files. Data 36 may also be formatted in any computer-readable format such as, but not limited to, binary, ASCII or Unicode values.
[00021] Although the block diagram of FIGURE 3 illustrates the processor 30 and memory 32 as being within two distinct blocks, it will be understood by those of ordinary skill in the art that the processor and memory can actually comprise multiple processors and memories that can or not be stored within the same physical cabinet. For example, some of the data 36 may be stored on a removable CD-ROM and some within a read-only chip. Some or all of the data 36 may be stored in a physically remote location and still accessible by the processor. Similarly, the processor may actually comprise a collection of processors that may or may not operate in parallel.
[00022] The communications network interface device 38 is capable of establishing wired or wireless communication links with other devices over a communication network, such as network 20. Network 20 may be any wired communications network or wireless, such as the Internet, a WLAN, a LAN, or other communication network system. The communications network interface device 38 of the SARD 14 communicates with the other devices on the network, and particularly the RDA clients 18 using a predetermined protocol. In at least one embodiment, the SARD 14 communications network interface device 38 uses the OpenADR (Open Automated Demand Response) protocol developed by Lawrence Berkeley National Lab.
[00023] Continuing with reference to FIGURE 3, data 36 in memory 32 of SARD 14 includes information to determine whether data is included in or derived from a message, such as an XML document or in SOAP packets, received at the mail server. RD 14 from an authorized entity (for example, a manager of the electricity distribution company) over a communication network 20, corresponds to a request to inform the customers of RDA 18 that an DR event will occur. Consequently, data 36 in memory 32 provides sufficient information for processor 30 to determine, from the received electronic message data, details of the RD event, such as the start time, stop time, and each mode for the RD event. RD. The modes for DR events indicate different levels of urgency or required operating levels for the DR event. For example, the modes for an DR event can be a "moderate" mode, a "high" mode, or a "special" mode (eg an "extreme" mode) or any serial combination of these modes. Each mode for an RD event (also referred to in this document as an "RD mode") is communicated in one or more RD event messages 99 from SARD 14 over network 20 via communications network interface 38. The communication of an RD event will also include a date and time for the RD event.
[00024] The SARD 34 application is configured to detect the reception of electronic message data, such as XML documents or in a SOAP packet, in the communications device 108 transmitted over the network 20 from an electric power distribution company , processing the electronic message data, determining an RD event indicated by the electronic message data, and also the details of the RD event, such as the timing and one or more modes of the RD event, included in the electronic message data. The SARD application 34 is then configured to generate an RD event message and correspond to the RD event for the RDA clients 18.
[00025] Additionally, the SARD 34 application can be additionally configured to monitor data received over network 20 from RDA 16 clients and also from other sources, such as third-party weather data sources, and to store the data in memory 32. RDA customer
[00026] Referring now to FIGURE 4, each end user 16 includes an RDA client 18 that is electrically and/or communicatively connected to a building automation system 22. The RDA client 18 can also be electrically and/or communicatively connected to an electricity consumption meter 40 or directly or through SAP 22. The RDA client 18 can be configured with a processor 50 and a memory 52. The RDA client 18 can be a personal computer or workstation, intended to use by a person, which is configured for specialized operation as a demand-response interface to a SAP 22. in the modality shown in FIGURE 4, the RDA client 18 has all the internal components normally found in a workstation, such as as a central processing unit (CPU) 50, a user interface 60 including a display device 62 (such as a monitor) and user input devices 64 (such as a mouse, keyboard, screen and touchscreen, microphone, speakers), CD/DVD controller (memory portion 52 in FIGURE 4), and a communications network interface device 68. In at least one embodiment as described in this document, the RDA 18 is provided by the same workstation used to run control programs for the building automation system 22. In other embodiments, the workstation used to provision the RDA 18 client may be a separate workstation that is connected via from a network to a workstation used to run the control programs for the building automation system.
[00027] User interface 60 communicates with processor 50 through various input/output ports 58 and related interfaces. Memory 52 can be any type of memory capable of storing information accessible by the processor, such as a hard disk, memory card, ROM, RAM, DVD, CD-ROM, read-only memories, or other computer-readable medium. The information contained in memory 52 includes instructions 54, 100 and data 56. User input devices 64 serve as an interface that allows a human ("operator" or "end user") to modify the data in memory 52.
[00028] The memory 52 of the RDA client 18 includes various programs that can be executed by the processor 50. In particular, the memory 52 includes a SAP controller program 54 configured to send instructions to the field panels 42 of the SAP 22 in order to control and monitor multiple devices 44 of SAP 22. In one embodiment, the SAP controller program 54 may be provided by SAP APOGEE® INSIGHT control software commercially available from Siemens Industry, Inc. or SAP control software.
[00029] In addition to the SAP controller program 54, memory 52 also includes a program identified in FIGURE 4 as the "RDA Client Application" 100 (which may also be referred to in this document as the "RDA application"). The RDA Client Application 100 is configured to receive RD messages from the SARD application 34 through the communications network interface device 68. As explained in further detail below, the RDA Client Application 100 also determines a control schedule to the devices 44 of the SAP 22 in response to an RD event message. The RDA Client Application 100 communicates with the SAP controller program 54 so that the SAP devices 44 can be controlled as determined by the RDA Client Application 100. A user interface application 160 is also provided in memory 52. represented by the dotted lines in FIGURE 4, the user interface application 160 may be a separately executable program or a program module of the RDA Client Application 100 that works in association with the RDA Client Application 100 to provide an output or receive a Entrance. In particular, the user interface application 160 uses the components of the RDA Client Application 100 to generate and display one or more screens of output to a human user and receive input from the human user via the physical user interface 60 to use by the RDA 100 Client Application as described in further detail in this document. For clarity in the discussion, user interface application 160 may also be referred to in this document as "ARD 160 client user interface".
[00030] Continuing with reference to FIGURE 4, the SAP 22 includes a number of field panels 42 or similar controllers configured to automatically control various devices 44 in the building automation system 22 based on instructions received from the SAP controller 54. RDA Client application 100 also performs programming for various SAP devices 44 based on data 56 in memory 52. Data 56 in memory 52 includes RD event message information received from SARD 14 via communications network interface 68. Data 56 in memory also includes various setpoints and control data for the RDA 100 application client, which can be pre-installed in memory 56 or supplied by the user through the various input devices 62. Additionally, historical data , registration and licensing for the application of RDA 100 are retained as data in memory 52. The operation and functionality of the application client of RDA 100 are described in further detail below with reference to FIGURES 5 to 16.
[00031] Continuing with reference to FIGURE 4, the RDA client 18 is connected to the building automation system 22 via a SAP Communications Interface 48. The RDA client 18 is configured to distribute control signals to the automation system building 22 based on various DR event messages received from the SARD 14. The building automation system 22 includes one or more 42 field panels or other controllers configured to control and/or monitor the operation of various 44 devices or "points" " within an end-user installation 16, such as 44A HVAC systems, 44B lights, 44C coolers, and various other 44D and 44E devices or systems. A "point" as referenced in this document that is controlled and/or monitored by a field panel 22 may refer to a respective device 44 or a respective input or output of this device 44. An exemplary building automation system for use in association with the RDA 18 client is described in US Patent No. US 7,664,574, filed February 16, 2010, the contents of which are incorporated in their entirety herein by reference to the extent permitted by law. The RDA client 18 is configured to communicate with the SAP 22 via the SAP Communications Interface 48 using one of several communication protocols that can be recognized by the SAP 42 controllers, such as BACnet or SOAP.
[00032] The electrical energy meter 40 can be electrically and/or communicatively connected to the field panel of the SAP 42 and is used to monitor the energy consumed at the customer's installation 16 associated with the respective field panel of the SAP 42. The meter power supply 40 is a conventional or "smart" device that can be connected at the point from which mains electrical power is supplied to an end user, and also an electrical power line to which supplementary electrical power is supplied to the user. Final. The meter 40 includes components for monitoring the use of electrical energy from the network and the supplemental power source, and transmitting, over a wireless or wired communication network to the SAP 22 (and/or to the RDA client 18 ), in real time, representative data of the electrical energy being consumed from the power grid and the supplemental energy source that provides supplemental electrical energy to the end user 16. In one embodiment, the energy meter 40 may be a submeter, smart meter or similar meter that provides to the SAP 22 (and/or to the RDA 18 customer) this electrical energy related information such as KW demand, KWH usage, voltage phase, phase and amperage, power factor , KVAR and harmonics. RDA Application Architecture
[00033] Referring now to FIGURE 5, a high-level functional block diagram of the architecture for the RDA 100 application is shown. The RDA 100 application resides within the memory of the workstation providing the RDA 18 client ( represented by dotted lines in FIGURE 5). As previously described in FIGURE 4, the SAP controller 54 may also reside within the memory of the workstation providing the RDA client 18. This embodiment is represented in FIGURE 5 by the SAP controller software 54 which is provided in dotted lines 18 representing the RDA client workstation.
[00034] In one modality, the RDA 100 application is configured to operate with a Microsoft Windows® operating system (not shown in the figures). However, the RDA 100 application can be implemented to operate with other operating systems, such as Linux or Unix, without deviating from the present invention. In the embodiment of FIGURE 5, the RDA application 100 includes a plurality of modules that include a model repository 110, a licensing module 112, a UI communications module 114, a programming module 116, a history module 118, a registration module 124, a BACnet adapter module 120 (or other SAP network protocol adapter module), a Simple Object Access Protocol ("SOAP") adapter module 122 (or other communication protocol for exchanging structured information between Web Services over a network), and an RDA 102 Client interface module. The model repository 110 manages these RDA 100 application modules, which can be run serially or segmented, to perform multiple processes related to an RD event, for example, as explained in further detail below, the RDA application is configured to prepare a schedule for the SAP devices and provide control messages for the count. SAP roller 54 when an RD 99 event message is received from the SARD 34 application.
[00035] The Model 110 repository is the central processing and communications component of the RDA 100 application. The Model 110 repository is configured to receive an RD 99 event message from the SARD 14 through a Client interface of RDA 102. The RD 99 event message generally includes a unique RD event ID (for example, "RD Event One"), a notification time that indicates when the RD 99 message was transmitted by the SARD 14, a start date and time (eg 13:00 on August 1, 2011) for the RD event, and end date and time for the RD event (eg 18:00 on August 1, 2011) , and one or more RD 99a commands that indicate operational states or "modes" within the RD event (also referred to in this document as "RD modes"). Each mode within the DR event indicates the severity of load shedding required for that period or part of the DR event (eg a "moderate" mode, "high" mode, "special" mode, etc.). Each RD 99a command that identifies a mode in an RD event can also have a mode start time and a mode end time. RD 99 event messages may be sent to RDA 102 client interface as a result of message generation by SARD 34 application. Alternatively, RDA 102 client interface may periodically poll SARD 34 application to determine whether an RD 99 event message is available. Upon receiving the event message from RD 99, the application client of RDA 100 acknowledges receipt of the message for the SARD 14 via the client interface of RDA 102, and the event message from RD 99 is distributed to the repository of model 110 for processing.
[00036] A history of RD 99a event commands received by the RDA 102 client interface is maintained in history module 118. History module 118 keeps track of all RD events that have been received by the system, and is capable of providing a graph or tabular view of DR events to the end user, as described in further detail below with reference to FIGURE 14.
[00037] Continuing with reference to FIGURE 5, the model repository 110 is in communication with a license module 112. The license module 112 provides data to the model repository 110 concerning the status of a license it grants to the end user the authority to run and use the RDA 100 application on the RDA client computer 18. If an end user is licensed to use the RDA 100 application, the license module 112 provides a confirmation to the model repository, and the Model repository proceeds to run the RDA 100 application software. If license module 112 indicates that the end user is not licensed to run the software, or has yet to accept the end user's license agreement, the model repository prevents the RDA application 100 from running, and displays an appropriate message via the user interface application 160.
[00038] The model repository 110 communicates with the UI application 160 through the UI communication module 114 which transfers messages to the UI application 160 and receives messages from the UI application 160. The user interface application 160 includes a run-time communication module 166 that provides the model repository outputs to the physical user interface 60, which includes the display 62 and other outputs, and therefore provides to the operator. access to information in the model repository 110. The runtime communication module 166 also facilitates input from the operator through user input devices 64. As explained in further detail below, inputs received from the end user are used by the 110 model repository to automatically determine what actions should be taken during an DR event.
[00039] The model repository 110 is also in communication with a programming module 116. As explained in further detail below, the programming module 116 determines which actions must occur for a point identified in SAP 22 before, during and after each mode RD specified in an RD 99 message received for an RD event or in reference to the start or end of the RD event. The programming module 116 also resolves conflicts if (i) conflicting control actions are associated with a device or point on the SAP 22 to be controlled in response to a specified RD mode for an RD event, and/or (ii) multiple DR modes specified for an DR event result in conflicting actions with one or more devices or points in the building automation system 22.
[00040] Model repository 110 is configured to distribute messages to field panels or other SAP controllers 42 of building control system 22 using a communications module of SAP 120. As shown in FIGURE 5, the module SAP communications 120 can be configured to deliver messages to field panels 42, or it can be configured to deliver messages to software controller SAP 54, which then passes control messages to field panels 42 of SAP 22 using the protocol used in SAP 22, such as the BACnet communications protocol. Accordingly, in the embodiment of FIGURE 5, the SAP communications module 120 is a BACnet adapter, and a BACnet server 46 is provided by the SAP controller software 54. As a result of receiving messages from the SAP communications module 120 , the SAP 42 field panels process the messages to control the devices of the building automation system 22. The controllers of SAP 42 can also return confirmation messages to the model repository 110 to indicate the status of certain devices of the automation system building 22 (for example, confirm that the lights have been dimmed).
[00041] In addition to communicating directly with the SAP 42 field panels and the BACnet 46 server, the model repository 110 can also communicate with a SOAP server 47 through a SOAP communications module 122 using the SOAP protocol. Messages received by SOAP server 47 can be, for example, information messages provided to an operator of the building automation system 22 to inform the operator of various operations or situations related to the RD event.
[00042] All actions taken by the model repository 110 are stored in a registration module 124 of the RDA 100 application. Consequently, the registration module 124 provides a tool that controls the internal operation of the RDA 100 application. of an error in the RDA application, the logging module 124 provides valuable information that can be used to help determine the source of the error in the system.
[00043] The RDA 100 application client described in this document can be easily rolled back into existing building automation systems. Since the RDA application client 100 can be installed on the same workstation as the SAP controller 54, communications between the RDA application client 100 and the SAP controller 54 can be easily implemented within the workstation. . The SAP controller 54 prepares commands to control devices of the SAP 22 based on communications with the RDA 100 application client.
[00044] It should also be recognized that the RDA 100 application client described in this document can be configured to interface with any number of different types of automation systems, which includes factory automation systems, home automation systems, and other systems of automation. The implementation of the RDA 100 application client with these different building automation systems can be consistent with the interfaces described in this document in order for the building automation system 22 to provide the user with configurable demand response strategies and techniques for responding to commands of RD that correspond to an RD event from an RD server 14, which includes those strategies and techniques described in further detail below. Demand Response Audit SAP Point Control Strategy
[00045] A licensed user of the RDA 100 Application may be the owner or operator of an industrial, commercial or residential facility that includes a building automation system 22. For example, FIGURE 6 shows an example commercial building 600 with a plurality of floors or other building automation "zones" and a building automation system 622 configured to control a plurality of building control systems 610 and related devices in each zone. Building control devices and systems include building environmental control systems such as HVAC 624 systems and related 626 lighting devices and systems and related devices. Control systems and devices may also include other energy consuming devices that are unrelated to the environment within the building, such as 628 car charging stations, telephone chargers and handheld devices, refrigerators, ovens, televisions, computers, etc. The building automation system 622 can also be configured to control various security systems, such as fire alarm systems or burglar systems. If the commercial building includes any industrial capability, the building automation system can be further configured to control power for various industrial machines used within building 600. The term "points" can be used to refer to a particular controlled device or system by a building automation system, or to an input or output of this device or system.
[00046] In addition to energy consuming devices, commercial building 600 may also include or be associated with various energy producing devices, such as a weathervane 630, solar panels 632, or a generator 634 configured to burn fossil fuel in order to supply energy for building. If excess energy is produced by the energy producing devices, the excess energy is distributed to the electrical power grid 24 (see FIGURE 2), and the utility company compensates the proprietary building for the excess energy produced.
[00047] Building 600 shown in FIGURE 6 is equipped with an RDA 18 client computer (not shown in FIGURE 6) that receives RD 99 event messages from SARD 14 which is remote from building 600. the owner of building 600 uses the RDA application client installed on the RDA client computer, and responds effectively to RD events, the building operator first has to conduct an audit of the devices within the building 600 and determine which devices will be affected when an RD event occurs. When conducting this audit, the building operator may discover that three different types of DR events are possible, such as a moderate DR event, a high DR event, and a special (or extreme DR) event. During the audit process, the building operator reviews the various points within the SAP and decides which points are available for reduced energy consumption depending on the type of DR mode. For example, the building operator can determine during the audit process that the HVAC can allow the temperature on all floors to be raised to different degrees for different DR modes. As another example, the building operator may determine that lights on most floors can be dimmed during all DR events, but that lights on certain floors should never be dimmed (for example, if fabrication occurs on certain floors, a lighting level limit may be required at all times). Therefore, during the DR audit, the building operator identifies various SAP points that can be controlled to respond to RD events of various levels. After identifying these SAP points that will be tracked in response to DR events, the building operator then has to come up with a strategy for how and when the SAP points will be tracked.
[00048] After performing the audit described in the previous paragraph, the building operator then maps a strategy to reduce the building's energy consumption to arrive at the desired load reduction for each different DR event type or for each DR mode or serial combination of different RD modes that can be specified for an RD event. FIGURE 7 shows an example of a demand reduction strategy worksheet 700 produced by a building operator to configure the RDA 100 application according to the present invention, where different SAP devices are targeted for reduced power consumption based on different RD events, where different RD modes or serial combinations of them can be specified for different RD events. The worksheet includes indicating building operation parameters and power consumption based on various RD modes that can be specified as RD 99a commands of an RD 99 event message received by the RDA 100 application from the SARD server. In particular, the spreadsheet includes (i) a first column 702 that indicates "normal" or "default" conditions for points or devices within the SAP 22 when there is no RD event or RD mode (eg no reduction target in power consumption), (ii) a second column 704 indicating a "moderate" DR mode for an DR event (e.g., a 200 kW target reduction in power consumption), (iii) a third column 706 which indicates a "high" DR mode for an RD event (eg a 400 KW target reduction), and (iv) a fourth column 708 which indicates a "special" RD mode for an RD event (by example, a target reduction of 600 kW).
[00049] In the first column 702 of worksheet 700, it can be seen that the building operator has determined a set of typical or "normal" operating conditions for the building. In this normal state, the building's cooling installation consumes 42.45% of total capacity, fans and HVAC air handling devices consume 14.15% of total capacity, lighting systems consume 22.26% of total capacity, plugged-in items in various electrical outlets consume 5.56% total capacity, various electrical devices and the processing and data center consume 8.9% total capacity, and car charging stations consume 6.68% total capacity. This total consumption is shown as 1797 KW in the example in FIGURE 7.
[00050] At the same time that energy is being consumed, some energy is being produced by the building. In particular, the building's wind turbine is operating at full capacity and provides 2.78% of the total energy needed, and the photovoltaic cells provide 10.01% of the total energy needed. As a result, under normal operating condition, the building only needs to buy 87.20% of the total energy required from the electricity distribution company through the electricity grid. In the example of FIGURE 7, this total energy purchased for a given time is 1567 KW.
[00051] In the second column 704 of the worksheet, the building operator has determined in this example, in the case of a "moderate" DR mode or DR event, that power consumption can be reduced by something above 200 KW by manipulating certain points in the building automation system. In particular, the building operator has determined that when a DR event or "moderate" DR mode occurs, the building can reduce power consumption by 325 KW by increasing the temperature in the building by 3 degrees, reducing lights in the building by 20% and stopping all car loads. the transition to increased temperature, dimmed lights, and interrupted car loads starts before the start time of the RD event (or, alternatively, before the start time of the RD mode) in order to allow the system to gradually reach the new operational state and avoid sudden changes that must be easily recognized by humans. For example, the 3 degree drop in temperature can start one hour before the DR event start time and the lights dimming can start 5 to 10 minutes before the DR event start time. These actions result in a cooling load reduction greater than 10% and a lighting load of approximately 20%.
[00052] In the third column 706 of the worksheet, the building operator has determined that in this example, in the case of a "high" DR or DR mode event, the power consumption can be reduced by approximately 500 KW by manipulating certain points in the system of building automation. In particular, the building operator has determined that when a "high" DR or DR mode event occurs, the building can reduce power consumption by 489 KW by increasing the temperature in the building by 6 degrees, reducing the lights in the building by 30% and stopping all car loads. Again, the transition to increased temperature, dimmed lights, and interrupted car loads begins before the RD event start time (or before the RD mode start time).
[00053] In fourth column 708 of the worksheet, the building operator has determined in this example that, in the case of a "special" DR event, power consumption can be reduced by more than 750 KW by manipulating certain points in the automation system of the building. In particular, the building operator has determined that when a "special" DR event occurs, the building can reduce power consumption by 759 KW by increasing the temperature in the building by 6 degrees, reducing the lights in the building by 40% and stopping all loads of cars. Again, the transition to increased temperature, dimmed lights, and interrupted car loads begins before the RD event start time (or before the RD mode start time).
[00054] FIGURE 7 shows that the building operator can determine to control various points of SAP 44 using the RDA 100 application differently depending on the event mode of RD 99 (ie "moderate", "high" or "special" ). However, it should be recognized that the building operator can also control the various SAP points depending on other factors such as the time of day of the DR event, the time of year of the DR event, and the size of the DR event ., for example, if an DR event occurs in the middle of the day in summer, the building operator may choose to dim the lights by a greater degree, but keep the temperature in the building closer to a normal temperature. The reason for this is that the building is likely to receive significant amounts of ambient light through windows in the building, so lighting will be less important to workers in the building at this time than the temperature in the building. Similarly, if the DR event is at night in summer, the building operator may choose to keep the lights closer to full intensity, but allow the temperature in the building to increase to a higher degree as the lighting in the building will be most important to workers at this time. Therefore, even though the response strategy mapped in the worksheet of FIGURE 7 only considers the DR event mode for the sake of simplicity in the example, it will be recognized that more complex strategies that consider other DR event factors such as time of day, season , and DR event dimension, will typically be mapped by the building operator.
[00055] It will be recognized that FIGURE 7 shows a very simple example of a strategy to respond to various modes of an DR event. The more complex the SAP and the number of associated devices, the more complex the DR event strategy will generally be. In any event, when completing an RD event strategy the user will generally, (i) identify multiple SAP points to control in association with different modes of an RD event, (ii) determine any time offset for control of each point before the start of the RD mode or event, (iii) determine time offset to control each point following the end of the RD mode or event. Following this, the user can configure the RDA Application 100 to execute the mapped DR event strategy. RDA Application Configuration
[00056] After the building operator completes the building audit and maps a control strategy to various SAP points, the building operator configures the RDA 100 application for an appropriate or strategic response to a DR event, which includes a RD pre-mode processing strategy and an RD post-mode strategy for responding to each early RD command 99a. The RDA 100 application can generally be configured according to one of three options for processing the RD 99 event message received from the SARD 14. Each of these three options is explained briefly in the following paragraphs.
[00057] According to a first option to configure the RDA 100 application, the RDA 100 application generally serves as a pass-through translator component that distributes the RD 99a command (specified in an RD 99 event message) to the building automation system 22 according to the building automation system communications protocol (eg BACnet or other protocol). In particular, the application of RDA 100 distributes the event information from RD 99 to various field panels 42 of the building automation system 44. In this modality, all response strategies and RD event control actions are programmed directly in the panels of field 42 in your particular language (for example, PPCL or other equivalent control programming language). Thus, under this first option, the RDA 100 application is not used to implement the strategies that result from the RD audit, and merely serves as a pass-through translator component for the RD 99a commands specified by or associated with the RD event for delivery to SAP 22 after translating these RD 99a commands into SAP 22 communications protocol.
[00058] According to a second configuration option, the application of RDA 100 is used to determine the points of SAP 44 that will be controlled and a schedule for associated actions in response to a command of RD 99a that can be specified or associated with the RD event. In this option, the building operator uses the graphical user interface 60 of the RDA client 18 to program the RDA 100 application to respond to various RD commands as determined by the response strategies for the RD audit. Once the response strategies are entered into the RDA client 18 by the operator, the RDA 100 application automatically generates a response corresponding to each RD mode that can be specified by an RD 99a command in an RD 99 event message received from the RD server 14 based on the devices or points 44 and corresponding control actions for the devices or points that have been identified to the RDA 1 10 application as being associated with the specified RD mode. Additionally, the RDA 100 application includes a scheduler component (see reference numeral 116 in FIGURE 5) that automatically generates a schedule of control actions for various SAP points in response to each RD 99a command specified by a respective event message of RD 99. Further details of the operation of programming component 116 will be explained in further detail below. The programmer component 116 of the RDA 100 application also includes a conflict resolution feature that prevents operational conflicts at the various points of SAP 44 based on (i) conflicting control actions in the pre-processing strategy to control a respective point of SAP 44 in response to a respective RD command or RD mode specified in an RD event 99, where conflicting control actions are associated with overlapping control periods relative to the RD mode start time for the RD event and the RD event end time; (ii) conflicting control actions in the post-processing strategy to control a respective SAP 44 point in response to a respective RD command or RD mode specified in an RD 99 event, where conflicting control actions are associated with overlapping control periods relative to the RD mode end time for the RD event and the RD event end time; or (iii) the post-processing strategy of a response to a first RD command specified in an RD 99 event and a subsequent RD command specified in the same RD 99 event, as will also be explained in further detail below. After the scheduler component prepares the schedule of actions to control the SAP 44 points, the RDA 100 application implements the schedule by sending control messages to the SAP 42 field panels at the appropriate times to control multiple SAP 44 points. RDA 100 application being able to communicate with the SAP 42 field panels according to the communications protocol of the building automation system (eg BACnet or other protocol), all Demand Response programming can be obtained from the RDA client, and there is no need to perform additional programming on the SAP 42 field panels (eg using PPCL or other control programming language). For example, in an embodiment in which the SAP field panels 42 employ the BACnet communication protocol and the SAP controller 54 has a corresponding BACnet server 46 to control the SAP field panels, the RDA 100 application of the customer. RDA 18 can be configured to provide or "stack" BACnet control commands to the BACnet server 46 of the SAP controller 54 in accordance with the schedule of actions generated by the application of RDA 100 to respond to the series of RD commands or RD modes specified by the RD 99 event received by the RDA 100 application. Consequently, the RDA 100 application is useful in rehabilitating existing building automation systems with Demand Response capabilities without the need for additional programming of the SAP field panels.
[00059] According to a third configuration option, the application of RDA 100 is configured to include components of the first configuration option and the second configuration option described above. Additionally, additional programming on the SAP field panels may be required to perform certain DR control actions, for example, under this third configuration option, the application of RDA 100 processes an RD 99a command and generates the appropriate RD response for various SAP points, similar to that described above with reference to FIGURE 2. Under the third configuration option, the response strategies entered in the RDA Client act as flags to enable or disable the execution of the control programming blocks that are predefined. -programmed in the SAP field panel 42. Similar to the second configuration option, the scheduler component 116 automatically generates an action schedule for various SAP points in response to each RD 99 event message.
[00060] When the building operator decides to configure the RDA 100 application under one of the configuration options, the RDA 18 client receives several SAP 44 points that will be controlled by the RDA 100 application. In order to program the SAP points 44 in the memory of the RDA Client 18, the building operator makes use of the RDA Client 160 user interface. An exemplary embodiment of a screen generated by the RDA Client 160 user interface that can be used to program SAP points 44 in the RDA client 18 for processing by the RDA 100 application is shown in FIGURE 8. Screen 800 is titled "List of Points". This screen includes a table 802 that lists all BAC points stored or known by the RDA 100 application. The RDA 160 Client user interface allows a user to add new points to table 802 by pressing a button 804 displayed on screen 800 and remove points from table 802 by actuating another button 806 displayed on screen 800.
[00061] By acting or clicking on the 804 button, the user signals the RDA 160 Client user interface to add a new row to table 802 so that the user can identify a new BAC point added to table 802. shown in FIGURE 8, the user enters the name of the new BAC point to be controlled by the RDA client 18 in column 810. In one embodiment, the point name is mapped by the RDA Client 160 user interface to the network address of the respective point in the building automation system 22 so that the RDA 100 Client Application can send control actions to the corresponding point based on the point name. For example, the RDA Client user interface can employ the point name mapping to a network address and device type using an industry standard network mapping protocol such as the BACnet protocol as further explained below. In this mode, the name entered in column 810 can be any name chosen by the user, and generally identifies the type of point and a location (or building zone) for the point.
[00062] After entering the point name, the user identifies to the RDA 100 Client Application in column 812 whether the point will be a notification point or a response point. Notification points are generally those points that indicate the status of an DR event. Response points are generally those points that will control building environments or a building device in response to an RD command.
[00063] Continuing with the example shown in FIGURE 8, the user identifies to the RDA 100 Client Application in column 814 the network of the building automation system where the point resides. Next, in column 816, the user identifies the device ID or network address to the RDA 100 Client Application. In column 818, the user assigns a value type to the named point. The value type can be selected from a drop down menu associated with column 818. Sample value types can be analog values, binary values, or multistate values. For example, the fan speed setting on line 830 can be an analog value, which indicates that it can be any of several numerical values. As another example, the source pump on line 834 can be a binary value, which indicates that the pump is either on or off.
[00064] In the example shown in FIGURE 8, an object ID is identified by the user to the RDA 160 Client user interface in column 820. The identified object ID is used by the RDA 160 Client user interface and by the RDA 100 Client Application to associate the corresponding point in table 802 with a certain type of device. For example, object ID "7" might identify the point as a fan, while object ID "2" might identify the point as an air handling unit. Finally, the user identifies to the RDA Client user interface 160 a priority level to associate with the corresponding point in column 822. The priority level generally indicates the relative weight that control of this point should receive by the RDA Client Application 100 and SAP 22 regarding other points 44 in SAP 22. The Client Application of RDA 100 can use this priority level data in column 822 when generating a schedule and resolving conflicts, as described in further detail below.
[00065] In another embodiment, the point name identified by the user in column 810 of table 810 corresponds to the network address naming convention of the respective SAP 22 so that the RDA 160 Client user interface and the RDA Client Application RDA 100 do not need to map the respective point name to the network address and device type of the respective point in SAP 22. In this modality, SAP 22 can store a table of point names in SAP 22 that are controlled and/or monitored and mapped to the physical location of the points in the SAP 22 network to facilitate communication with the respective points. In this mode, the user specifies to the RDA Client user interface 160 the point name in column 810, whether the corresponding point is a notification point or a response point (or "use type") in column 812 and the point's priority level relative to other points in column 822 so that the RDA 100 Client Application can then send control actions to the corresponding point based on at least the point name, usage type and corresponding priority level.
[00066] The RDA 160 Client user interface additionally allows a user to delete points that were previously added to the system by pressing button 806 on screen 800. This allows the user to modify the building control system defined within the client of RDA 18 both during initial configuration and at a later date in the event that the building undergoes changes that diminish certain points or devices associated with certain points of the building automation system 22.
[00067] After the user assigns points to the RDA Client 18 using the RDA 160 Client UI as described, the RDA 160 Client UI allows the user to specify each point 44 that is to be configured for actions control in response to each RD command or RD mode that can be specified in any RD 99 message for an RD event. As previously mentioned, each RD event includes one or more modes (e.g., "moderate", "high", and "special" modes), and each RD 99 message includes one or more RD 99a commands that are associated with each. one with a respective mode. In order for the RDA 100 application client to properly control SAP points during an RD event based on the one or more commands 99a in the corresponding RD event message 99, the user identifies to the RDA 100 application client (via from the RDA Client user interface 160) each point 44 of the SAP 22 that will be associated with an RD mode (or corresponding RD command 99a) that is anticipated to be in an RD event message 99 so that the client application of RDA 100 is able to identify the points 44 to be controlled and command the corresponding control actions for the identified points 44 in response to the respective RD mode (or corresponding RD command 99a). For example, for each point 44 that is identified in table 802, the RDA Client user interface 160 allows the user to associate the respective point with an RD mode and identify how and when the point should be controlled (ie, the control actions for the point) during the mode of an associated RD event (that is, in response to a 99a RD command). In general, the RDA 160 Client user interface allows a user to configure or specify a control action for an identified point to be performed before, during and/or after a respective RD mode that can be specified by a command. corresponding RD 99a in an RD 99 message when processed by the RDA 100 Client Application for a next RD event. Additionally, the RDA 160 Client user interface allows a user to configure or specify a control action for an identified point to control before or after the specified start or end time of an RD event. In at least one embodiment, the RDA Client 160 user interface is further configured to allow the user to selectively specify control of a point identified by the RDA Client Application 100 before or after an RD event relating to the time of start or end of a respective RD mode specified for the RD event regardless of whether RD mode is the first or last mode specified for the RD event. In another embodiment, the RDA Client 160 user interface is further configured to allow the user to selectively specify control of a point identified by the RDA Client Application 100 before or after an RD event depending on the first or last mode of the DR event.
[00068] FIGURE 9A shows an example screen 900 generated by the RDA 160 Client user interface to allow the user to configure points for various control actions (which actions may be referred to in this document as "point control actions" ). In one embodiment, the RDA Client presents a point list 901 on a screen panel 900, where the point list includes the name or identifier of each point identified by the user to the RDA Client 160 user interface (for example , each point name identified in table 810). Each point name or identifier in point list 901 can be selected by the user through any 64 input device (eg mouse click, or touch screen input) to configure or assign point control actions using the RDA 160 Client user interface. In the mode shown in FIGURE 9A, the user selected the name or identifier for the point "AHU1.FAN.SPEED.MAX" (ie, fan speed of air handling unit 1) to configure or assign corresponding time clock actions. When the user selects the point to be controlled from the point list 901, the RDA 160 Client user interface presents a table 902 on screen 900 with the name or identifier of the selected point in column 904. RDA Client 160 then receives from the user a selected RD mode to assign to or associate with the selected point in column 904. In screen mode 900 shown in FIGURE 9A, the RDA Client 160 user interface allows the user to select an RD mode in column 906 from one of a plurality of RD modes presented in a drill-down menu to associate with the selected point. The RD event mode can be any of the possible RD event modes, such as "normal", "moderate", "high" or "special". For each point that is selected by the user to be configured, at least one row of table 902 is automatically configured by the RDA 160 Client user interface to assign or associate "normal" mode with the respective point. As discussed in further detail below, the RDA 100 application is able to access table 902 and use "normal mode" as an index on table 902 to identify control actions assigned or associated with each point identified in table 902 for the mode "normal" so that the application of RDA 100 can control the respective points after the end of an RD event, when the BCS 22 is returned to normal operating mode.
[00069] After the user selects the RD mode in column 906 (which is assigned and stored in table 902 in association with the point name or identifier in corresponding column 904 by the RDA 160 Client UI), the user interface RDA Client user 160 then receives from the user a "reference time" selected in column 908 to assign to or associate with the selected point in column 904 based on the respective RD mode assigned or associated in column 906. As explained in detail further below, when an RD 99a command is received in an RD 99 event message, the RDA 100 Client Application associates the RD 99a command with a corresponding RD mode and uses the corresponding RD mode as an index to identify the corresponding points in table 902 that have been assigned to be tracked based on the user-selected reference time 980 for the respective DR mode. In the mode shown in FIGURE 9A, the RDA Client user interface 160 receives the reference time and associates it with a respective point in table 902 through a user's "reference time" selection from a drill-up menu 909 provided by RDA Client in association with column 908. In this mode, the 909 drill-down menu can offer five reference time options in which the point will be controlled or programmed for control by the RDA Client Application 100. These five reference time options include ( i) when the selected DR mode (from column 906) is active (ie ACTIVE DR mode in drill-down menu 909 from column 908), (ii) before the selected DR mode is active or starts (ie. RD TIME START mode in column 908) deepening menu 909, (iii) after the selected DR mode is active or terminated (ie DR END TIME mode in column 909 deepening menu 908), ( iv) before the start of the event of DR relative to the start of the selected DR mode regardless of the order of the DR mode in the DR event (ie, START TIME EVENT in the drill-down menu 909 of column 908), and (v) after the end of the event DR relative to the end of the selected DR mode, regardless of the DR mode order in the DR event (ie, END TIME EVENT in drill-down menu 909 of column 908).
[00070] Since a reference time (ie a tracking time period associated with the RD event) is identified in column 908 (and assigned to and stored in table 902 in association with the point name or identifier in the column corresponding 904 by the RDA Client UI 160 and the RD mode identified in column 906), the RDA Client UI 160 then receives from the user an offset time selected in column 910 to associate with the respective reference time 908. Time shift 910 indicates the time the associated point will be controlled by the RDA 100 Client Application based on the identified reference time 908 and a corresponding control action identified in column 912 for the respective RD 906 mode associated with the respective Score. Therefore, if the identified reference time 908 is before the selected RD mode starts (ie, RD MODE START TIME), the offset time 910 indicates one hour before the identified DR mode start when a control action associated with point will be started by the RDA Client Application 100. If the selected reference time 908 is after the selected DR mode ends (ie RD MODE END TIME), the offset time indicates a time following the end of the identified DR mode when an associated control action for the point will be initiated by the Client Application of RDA 100. Similarly, if the selected reference time 908 is before the RD event starts (ie, START_EVENT_TIME), the offset time 910 indicates one hour earlier from the start of the DR event when a control action associated with the point will be started by the Client Application of RDA 100. Also, if the selected reference time 908 is after the DR event ends (ie, END_TIME_EVENT), the offset time indicates a time following the end of the identified DR event when an associated control action for the point will be initiated by the RDA 100 Client Application. Although no offset times are shown for the identified points in column 904 in FIGURE 9A, as FIGURES 9B through 9C, discussed in further detail below, show exemplary offset times 910 that can be entered by the user using the RDA 160 Client user interface to configure a time control action at a particular time or before or after a mode. RD.
[00071] To facilitate understanding of the time and time references shifted in columns 908 and 910, reference is made to the example RD event of FIGURE 11A. This exemplary RD event 1110 (consistent with the RD event message 99) includes two or more RD commands that each have an associated active period 1130 and 1140. As described in the previous paragraph, an event can be associated with one amount of different periods. These periods can include a pre-active event period 1120 (ie, a period of time immediately before the DR event begins), an active event period 1130 that includes one or more DR modes (ie, the DR period. real-time for the DR event with one or more active modes that occur during the DR event, such as modes 1130 and 1140), and a post-active event period 1150 (that is, a time period immediately following the event of RD finish). Additionally, each DR mode of the DR event may also include a pre-mode period (eg period 1121 which may be the same or different from pre-active period 1120) and a post-mode period (eg period 1132 or period 1151, which may be the same or different from post-active event period 1150). SAP 44 points can be controlled by the RDA 100 Client Application to take different control actions during different periods and different modes within an RD 11 10 event. Therefore, a point can be controlled in one way during a pre- event 1120 associated with an RD mode regardless of whether that RD mode is the first RD mode specified for the RD event, otherwise during a pre-mode 1121 period of the RD mode for the RD event, still otherwise during an active period of mode 1130 for the RD event, yet another during a post-mode 1132 period of mode 1130 for the RD event, yet another during an active period for another 1140 mode of the event of RD, and still another way during a post-event period 1150 associated with the other RD mode regardless of whether that RD mode is the last RD mode specified for the RD event. Consequently, as described above with reference to FIGURE 9A, the user can choose a time period to associate with the point control action in column 912. These various options are represented in FIGURE 11A as follows: (i) control point at a start of an RD mode (e.g., RD "high" pre-mode period 1121 in FIGURE 11A); (ii) control the point when RD mode is active (e.g., "high" mode period of RD 1130 or "moderate" RD mode period 1140 of FIGURE 11A); (iii) control the point following the end of an RD mode (e.g., "high" post-mode period 1132 or "moderate" post-mode period of RD 1151 in FIGURE 11); (iv) control the point at the start of an RD event (e.g. pre-event period of RD 1120 in FIGURE 11A, which is shown in FIGURE 11A as associated with "high" mode of RD 1 130, but a period RD pre-event can also be associated with "moderate" mode of RD 1140 for the same point); and (v) control the point at an end of the RD event (e.g., post-event period of RD 1150 in FIGURE 11A, which is shown in FIGURE 11A as being associated with "moderate" mode of RD, but one period post-DR event can also be associated with DR “high” mode for the same point).
[00072] Referring now to FIGURE 9B, there is shown another example 900 point setup screen generated by the RDA 160 Client user interface which includes offset times in column 910. In the example of FIGURE 9B, using the user interface of RDA 160 Client, the selected point (ie "AHU1.SAT.STPT") has been configured to control with offset times both at the beginning and at the end of two RD modes so that the RDA 100 Client Application schedules the respective pre-mode control action and respective post-mode control action for the selected point. To configure a control action under this scenario, the user specifies (and the RDA 160 Client user interface receives and stores in table 902 as data 56 in memory 52) three control actions for the selected point (ie, " AHU1.SAT.STPT") for each DR mode (ie three control actions for each DR mode under which the point will be controlled). The first control action is shown on line 930 and includes an identification of the control point (ie "AHU1.SAT.STPT"), the RD operating mode (ie "moderate"), the reference time (ie "RD MODE ACTIVE"), a time offset from zero, and the value to which the control point has to be commanded (see column 912). Therefore, in line 930, the identified point has been configured to control for a period when "moderate" mode is active (that is, the period for moderate mode defined by the RD 99a command, which is also commonly referred to as a "period of RD control"). The second control action is shown on line 932 and includes an identification of the control point (ie "AHU1.SAT.STPT"), the RD operating mode (again, "moderate"), the reference time ( that is, "RD MODE START TIME "), an offset time value to perform the control action before the start of RD "moderate" mode, and the value to which the control point has to be commanded. Therefore, on line 932, the identified point has been set to control for a period that starts fifteen minutes before the start of a "moderate" mode and ends when the "moderate" mode is active. This pre-mode period is also commonly referred to as an "DR control period". The third control action is shown on line 934 and includes a control point identification (ie "AHU1.SAT.STPT"), the RD operating mode (again, "moderate"), the reference time ( that is, "RD MODE END TIME"), an offset time value to perform the control action after the end of RD mode, and the value to which the control point has to be commanded. Therefore, in line 934, the identified point has been set to control during a period that starts at the end of the active period for "moderate" mode and ends five minutes after the end of the active period for "moderate" mode. This post-mode period is also commonly referred to as a "DR control period". In addition to setting this control point to “moderate” mode, FIGURE 9B also shows a similar setting for “high” mode with various control point action settings for DR control periods before, during and after mode. "high" active.
[00073] Referring now to FIGURE 9C, yet another example point setup screen 900 generated by the RDA Client 160 user interface is shown which includes hours shifted in column 910. in the example of FIGURE 9C, the selected point (or ie, "AHU1.FAN.SPEED.MAX") was configured using the RDA 160 Client user interface to handle with offset times both the start and end of two RD modes that either start or end an RD event. To configure a control action under this scenario, the user specifies (and the RDA 160 Client user interface receives and stores in table 902 as data 56 in memory 52) three control actions for the selected point (ie, " AHU1.FAN.SPEED.MAX") for each RD mode. The first control action is shown on line 950 and includes a control point identification (ie "AHU1.FAN. SPEED. MAX"), the RD mode of operation (ie "moderate"), the time (ie, "DR MODE ACTIVE"), a time offset from zero, and the value to which the control point has to be commanded (see column 912). Therefore, on line 950, the identified point has been set to control during a period when "moderate" mode is active (ie, the period for moderate mode defined by the RD 99a command, which is also commonly referred to as a " RD control period"). The second control action is shown in line 952 and includes a control point identification (again, "AHU1.FAN.SPEED.MAX"), the RD operating mode (again, "moderate"), the reference time ( that is, "EVENT_START_TIME"), an offset time value to perform the control action before the reference time which in this case is before the start time of the event of RD 99 in which the "moderate" mode of RD is specified, and the value to which the control point should be commanded. Therefore, on line 952, the identified point has been set to track for a period that begins five minutes before the start of any RD event where a "moderate" 99a RD mode or command is specified in an RD 99 event message received by the Client Application of RDA 100, and ends when the respective "moderate" mode of RD begins. This pre-event period is also commonly referred to as a "DR control period". In at least one modality, this DR control period defined before the start of an DR event occurs regardless of the DR mode order (for example , the "moderate" mode can be the second of two RD modes specified in a received RD event message 99a) within the RD event. The third control action is shown on line 954 and includes a control point identification (ie "AHU1.FAN.SPEED.MAX"), the RD mode of operation (again, "moderate"), the reference time (ie, "EVENT_ENDTIME"), an offset time value to perform the control action after the reference time which in this case is after the event start time of RD 99 in which the "moderate" RD mode is specified, and the value to which the control point should be commanded. Therefore, on line 954, the identified point has been set to track for a period starting five minutes after the end of any RD event where a "moderate" 99a RD mode or command is specified in an RD 99 event message received by the RDA 100 Client Application, and this control period ends when a next control action is commanded by the RDA 100 Client Application according to the next RD mode. The next RD mode may be a "normal" RD mode (such as "normal" RD mode 1160 in FIGURE 11A) if no other RD mode is specified for the RD event in the respective RD event message 99. This post-event period is also commonly referred to as a "DR control period". Similar to line 952, the control period defined in line 954 can occur regardless of the "moderate" mode order in the DR event. In case a user wants to achieve different degrees of demand reduction for different RD modes of operation (ie "moderate", "high" or "special"), the user can use the RDA 160 Client user interface to associate the respective point with different modes and configure different control point actions for each mode. Therefore, a user may want to configure a point to be controlled by the RDA 100 Client Application before or after an RD event with a plurality of different modes. For example, in FIGURE 9C, using the RDA 160 Client user interface, the user has configured the point "AHU1.FAN.SPEED.MAX" in association with the "moderate" mode on lines 950, 952 and 954, but it has also set the same point in association with "high" mode on the lines following line 954.
[00074] Referring again to FIGURE 9A, the user also enters a value to associate with the point control action in column 912. The RDA 100 application uses this value to provide control signals to the SAP 42 field panels so that the identified point is controlled in value (ie a point control action). As an example, the value "80" in line 916 indicates that the fan speed should be set to 80% of maximum during the active period of time in a "moderate" mode. Similarly, the "abandon" value in line 918 indicates that the fan speed should return to a normal operating state following the end of an DR event.
[00075] After entering the above information for an SAP 44 point to be controlled during an RD event, the RDA 160 Client user interface allows the user to add additional point control actions for the same SAP point or additional points using the "Add Row" button 920 displayed on screen 900. Additional control actions for the same SAP point may be desired if the point is controlled differently in different modes during an DR event, before the start of a SAP event RD, or after an RD event. Additionally, if the user wants to remove certain previously entered time control actions, the user can select the "Remove Line" button 922 presented on screen 900 by the RDA 160 Client user interface. RD events can be modified by the user over time through the RDA 160 Client user interface.
[00076] Referring now to FIGURE 10, an additional characteristic configuration for the RDA client 18 is to establish a communications link with the SARD 14. In one embodiment, the RDA Client user interface 160 generates and displays a screen of RDA 1000 Communications Setup to allow the user to establish the communications link between the respective RDA 18 client and the SARD 14. The RDA 1000 Communications Screen allows the user to enter a URL address for the SARD 14, and a polling interval to contact the server. The user also enters a username and password so that the RDA 160 Client user interface can use a user profile authentication technique to confirm that the user is authorized to make modifications to the communications link between the client of RDA 18 and SARD 14. Scheduling for Demand Response Events
[00077] Referring now to FIGURE 11A, an exemplary RD event 1110 is shown as processed by the RDA Application 100 according to an RD 99 event message received in graphic form with time along the x-axis and event mode when along the y axis.
[00078] The RDA application client is able to recognize that the RD 1110 event starts at 8:00 am and ends at 9:00 am as specified in the RD 99 event message. RDA recognizes that the RD event 1110 is associated with a number of different periods, which includes two active modes that correspond to two RD 99a commands specified in the RD 99 event message. In the example shown in FIGURE 11A, an active mode RD 1110 event is a "high" mode of RD 1130 that is active from 8:00 until 8:30.
[00079] The "high" mode of RD 1130 is immediately followed by a "moderate" mode of RD 1140 which is active from 8:30 until 9:00 when the RD 1 110 event ends. The RD event message 99 from the SARD 14 provides information of the modes for the RD event as RD 99a commands (see FIGURE 5) to the RDA client 18.
[00080] In addition to the RD event information provided by the RD 99 event message, a pre-event period of RD 1120 and a post-event period of RD 1150 can also be determined by the RDA client 18 through the Application RDA 100 client, based on offset hours 910 previously described with reference to FIGURES 9A through 9C. As shown in FIGURE 11A, as a result of determining that a first command of RD 99a in the RD message 99 currently being processed corresponds to a "high" mode of RD, the RDA Client Application 100 identifies points 904 in table 902 that are associated with a "high" mode of RD in column 906 and finds that at least one point has a reference time 908 that defines a pre-event start period of RD 1120 (e.g., associated "EVENT START TIME" with "HIGH" mode from RD to "AHU1.FAN. SPEED. MAX" in FIGURE 9C). In the example shown in FIGURE 11A, the RDA Client Application 100 recognizes from table 902 that this pre-event start period of RD 1120 associated with the "high" mode of RD to control the respective point starts ten minutes before the DR event. Similarly, the RDA Client Application 100 is able to recognize that the same point has a reference time 908 that defines an RD pre-mode period associated with the “high” mode of RD 906 in table 902. in the example Pictured in FIGURE 11A, this 1121 "high" DR pre-mode period is graphically reflected as the same time period as the 1120 RD pre-event period. However, the same point may have a pre-event start period of RD 1120 that starts earlier, but still overlaps the associated RD pre-mode period 1121. In this case, the RDA 100 Client Application recognizes that there may be conflicting control actions 912 specified in table 902 for the same point 904 and resolves the conflicting control actions 912 using a priority conflict resolution method described in further detail below with reference to FIGURE 12.
[00081] In a similar manner, as a result of processing each RD command 99a in the current RD event message 99 to identify each RD mode specified for the RD event, the RDA Client Application 100 uses the identified RD mode to identify the points in table 902 that require a 912 control action to be taken during a DR pre-event period, a DR pre-mode period, a DR active mode period, a post-mode period of RD, and/or a RD post-event period defined with reference to a respective reference time 908. Continuing with the example shown in FIGURE 11A, the RDA Client Application 100 is able to determine that at least one point in the table 902 associated with each "moderate" RD mode specifies a 1150 RD post-event end period for the point that has a zero offset ends ten minutes after the RD event. The RD 1120 pre-event start period is also a pre-high mode period, as the RD 1100 event starts in high mode at 8:00. Similarly, the RD 1150 post-event end period is also a post-moderate period, as the RD 1110 event ends in a moderate mode at 9:00. Additionally, because "high" mode 1130 is immediately followed by "moderate" mode 1140, a post-mode period "high" 1132 overlaps the active period of "moderate" mode 1140. Also, before and after the event of RD 1110 , the system is in a "normal" 1160 mode, as indicated by the normal mode bars from 7:40 to 8:00 and from 9:00 to 9:20 in FIGURE 11. This "normal" mode does not it is an RD 99a command as part of an RD 99 event message, but it is simply the default or normal operating mode of the system when an RD event is not occurring.
[00082] As mentioned previously, time control actions can be programmed before, during or after a particular active mode. In FIGURE 11, it can be seen that the "high" post-mode period 1132 overlaps the "moderate" mode active period 1140, and thus there may be some scheduling conflict between user-defined actions within a post-mode period " high" 1132 and a "moderate" mode 1140. Consequently, in order to avoid conflict, the RDA client 18 assigns a priority to each point control action based on the period of time the action is scheduled to occur for the respective event.
[00083] FIGURE 11B provides another graph representing the same RD event as FIGURE 11A, but in FIGURE 11B the RD event is shown as a step function 1170 that reflects the resolution by the RDA application client according to present invention of conflicting control actions. The 1170 rung function moves from a "normal" mode (ie no DR event) to a "high" mode at 8:00, from "high" mode to "moderate" mode at 8:30, and returns to "normal" mode at 9:00. Reference numeral 1180 indicates that the actual DR event occurs from 8:00 until 9:00. As shown by rung function 1170, two different DR modes occur during this DR event (ie, a high mode followed by a "moderate" mode). Reference numeral 1182 shows the ten minute period before the start of the DR event. This ten minute period 1182 is like a "high mode start" period (ie, a high pre-mode period) as an "event start" period (ie, a pre-event period). Reference numeral 1184 shows a "moderate mode start" period (ie, a moderate premode period). reference numeral 1186 shows a "high mode end" period (that is, a high RD post-mode period). Reference numeral 1188 shows a "moderate mode end" period (ie, a moderate DR post-mode period) as well as an "event end" period. It will be recognized that the size of the DR event in FIGURES 11A and 11B and the hours, pre-hours, and post-hours associated with active mode are merely illustrative, and these hours may change as determined by the RD event (i.e., the actual RD event data from the RD server), and as determined by the individual conducting the RD audit (ie the individual who determines the required time dimension for pre-event activities, pre-mode activities, post-mode activities, and post-event activities).
[00084] Although the times for the actual DR event in FIGURES 11A and 11B are received from the SARD server 14, it will be appreciated that the RDA client 18 schedules time control actions related to the RD event at different times from the event of real DR. In particular, the RDA client 18 plans to track the SAP point before the RD event (ie 1182), during the RD event (ie 1180) period, and after the RD event (ie. period 1188). Any of these periods when a point control action related to an DR event occurs may be referred to in this document as a "DR event control period" or a "DR control period" (ie, a "DR period demand response control"), regardless of whether it is a period before the actual DR event, during the DR event (which includes before, during, or after each RD 99a mode or command specified in an RD message 99 for the RD event), or after the RD event. by pre-processing control of multiple SAP 44 points before the actual start of the DR event, the RDA 18 client avoids offset hours that would otherwise be required if systems try to service each event at the exact time the event occurs. of RD starts. This also allows SAP to gradually transition to the DR event and/or respective DR modes specified for the DR event so that humans in the building are less inclined to notice that the DR event has started (eg by reducing the lights gradually 10 minutes before the DR event, humans are less likely to notice a significant change in lighting). Additionally, post-processing control of SAP points after the end of the DR event allows control of SAP points to be scaled, allowing the system to be smoothed back to normal mode with appropriate offset times as determined by the operator. edification.
[00085] The above description of FIGURES 11A and 11B suggests that overlapping periods of DR controls is possible for certain DR events., for example, reference numeral 1186 in FIGURE 11B identifies a post "high" mode of DR which is an DR control period that occurs concurrently with an DR "moderate mode active" control period. It is possible during this time that the RDA 100 application can be configured to control the same SAP point in a different way. For example, in the DR control period corresponding to the DR post "high" mode, the RDA 100 application can be configured to gradually return the lights to 100% from a 70% state. At the same time, in the control period of "moderate mode active" and RD, the application of RDA 100 can be configured to keep the lights at 80% brightness. As another example, the RDA 100 application can be configured to control the thermostat in a given building zone to 75 degrees in a first DR control period and to 72 degrees in a second DR control period that occurs simultaneously with the first DR control period. Therefore, it will be recognized that conflict resolution processing is desirable in order to avoid conflicts caused by applying RDA 100 when determining control operations for certain RD events and/or overlapping RD control periods that correspond to different RD modes .
[00086] FIGURE 12 illustrates a method implemented by the RDA Application 100 to try to resolve conflicts for the control of multiple SAP points when responding to an RD event. In particular, FIGURE 12 shows a table listing various RD 1210 modes and 1220 time references. The combination of an RD 1210 mode and a 1220 reference time that is indicative of a RD control period (as illustrated in FIGURES 11A and 11B) associated with the respective RD mode 1210. The table in FIGURE 12 also lists an order of execution priority 1230 for each type of possible RD control period (i.e., for each possible operating mode 1210 and combination of reference hours 1220). In this mode, the RDA Application 100 is configured to recognize or determine that larger numbers in the run order column 1230 of FIGURE 12 indicate a higher priority if a point control action of an RD control period conflicts with a point control action from another DR control period., for example, if a point control action controls a thermostat in "moderate" DR mode control period to go to 75 degrees, but in a control period post "high" DR mode the thermostat is controlled to go to 73 degrees, the RDA 100 Application is configured to use the priority graph of FIGURE 12 to assign priority to the action during the moderate DR mode control period to control the thermostat to 75 degrees, since the "moderate / active mode" combination is given a higher priority than the "high mode / end" combination (ie 60 is greater than 45, as noted in the table in FIGURE 12). This priority chart in FIGURE 12 is employed by Application of RDA 100 for scheduling activities according to the flowcharts or scheduling processes of FIGURES 13A to 13D. Of course, in alternative embodiments, without departing from the scope of the present invention, the application of RDA 100 can be configured to recognize that a smaller number in the run order column 1230 indicates a higher priority over a higher number in the run order column 1230.
[00087] FIGURES 13A to 13D show flowcharts for various processes performed by the RDA application client of FIGURE 5, which include a scheduling routing in FIGURES 13B and 13C and a conflict resolution scheduling screen in FIGURE 13D.
[00088] Referring now to FIGURES 13A to 13D, flowcharts are provided that reflect processes performed by the RDA Application 100 to schedule SAP point control actions for an RD event. Referring to FIGURE 13A, RDA 100 Application template repository logic 1310 begins with polling the SARD 14 for a new RD event (step 1312). In step 1314, the RDA Application 100 determines whether a new RD 99 event message is available from the SARD 14. If no new information is available, the RDA client's RDA 100 Application 18 waits for 1 minute (step 1316 ) before probing the SARD 14 again, as noted in step 1312. However, it is determined in step 1314 that information on a new DR event is available, so the RDA Application 100 receives and reads or parses the new event message of RD 99 (step 1318). The following RDA 100 Enforcement causes the RDA 18 client to acknowledge receipt of the new RD event message with the SARD 14 in step 1320.
[00089] As explained previously under the heading "ARDA Application Configuration", the RDA 100 Application template repository can be configured to operate under one of three different optional configurations. In step 1322, the RDA Application 100 model repository determines whether the RDA 100 application has been configured to operate under the first option. If so, the model repository 110 passes the received RD event message to the SAP field panels 42 at the start of the RD event via the BACnet adapter 120 without further processing or after translating the RD message 99 to the appropriate communication protocol, such as the BACnet protocol. If not configured to operate under the first option, the model repository of the RDA 100 Application determines in step 1326 whether the RDA 100 application has been configured to operate under the second option. If the RDA 100 application has not been configured to operate under the second option, the RDA 100 application model repository recognizes that it is configured to operate under the third option, and the RD event processing under the third option by applying RDA 100 occurs in step 1330. However, if the model repository 110 of the RDA 100 application determines in step 1326 that the RDA client 18 is in fact configured to operate under the second option, the RDA 100 Application activates or executes scheduler 116 at step 1328 before continuing processing at step 1312.
[00090] A flowchart showing the general operation of the programmer 116 of the RDA 100 Application is shown in FIGURE 13B. Initially, the programmer 116 reads the RD event information from the received RD message 99 and determines the RD control periods where the point control actions related to the RD event are to take place. Next, in step 1344, the programmer selects one of the DR control periods, and then selects a point control action for the selected DR control period. As explained previously with reference to FIGURES 7 and 9, the RDA 100 Application allows a user or building operator to pre-define these time control actions through the RDA client's RDA 160 Client user interface 18. After selecting one From the point control actions for a particular DR control period, the scheduler below adds the selected point control action to a schedule for the particular DR event. The schedule includes a sequential list of all points that will be controlled for the DR event (eg a thermostat to be controlled), a time to start point control or change point control (eg thermostat control will start at 20:00), a value for the point control action (eg a new temperature for a thermostat), a command priority to command the point, and a time to abandon point control (eg thermostat control will end at 20:30). Next in step 1350, the scheduler 116 of the RDA 100 Application determines whether all time control actions for the RD control period have been added to the schedule. If all the time control actions have not been added, the programmer 116 returns to step 1346 and selects another time control action for the selected DR control period. If all time control actions have been selected, scheduler 116 continues processing at step 1352 and determines whether all RD control periods have been processed for the RD event. If all RD control periods have not been processed, the scheduler returns to step 1344 and selects the next RD control period for which point control events will be scheduled. If all RD control periods have been processed, all time control actions for the RD event have been added to the schedule, and scheduler 116 continues processing at step 1354 shown in FIGURE 13C.
[00091] As shown in FIGURE 13C, the RDA 100 Application scheduler 116 next determines if there are any conflicts in the schedule (step 1354). In one embodiment, programmer 116 performs step 1354 by determining whether two time control actions refer to a single point (i.e., point name or identifier in column 904 of table 902) and have overlapping time control periods (that is, the period between start time and end time for a point control action overlaps the period between start time and end time for another point control action for the same point as the scheduler 116 is able to derive from RD modes 906, associated time references 908 and corresponding time offsets 910 to the respective point 904 identified in table 902). If there are conflicts to resolve in the schedule, the programmer then performs conflict resolution processing (step 1356), as described in further detail below with reference to FIGURE 13D.
[00092] Continuing with reference to FIGURE 13C, once all conflicts in the programming are resolved, the programmer 116 of the RDA 100 Application cooperates with the model repository 110 of the RDA 100 Application to execute the programming (step 1358) . In particular, model repository 110 monitors the schedule and a sync (which may be a counter program synchronized with the sync device (not shown in the figures) for the RDA Client 18 processor 50) to determine it is time to perform a stitch control action from programming (step 1360). When the time comes to perform a point control action from the schedule, the model repository 110 continues processing at step 1362 and sends a command to a SAP field panel 42 to control a particular SAP point 44 as noted in the schedule. This command is sent through the BACnet adapter 120 which allows the RDA client 18 to communicate with the SAP 22. Next, in step 1362, the model repository 110 of the RDA 100 Application determines whether to schedule for the event. RD is complete. If the schedule is not complete, the model repository returns to step 1360 and waits for the next hour when a point control action must be taken from the schedule. Once programming is complete, model repository 110 returns to step 1312 (in FIGURE 13A) and RDA Application 100 then continues to poll SARD 14 for new RD event message.
[00093] FIGURE 13D shows a flowchart for an exemplary conflict resolution process or subroutine that can be performed by programmer 116 of RDA Application 100 in step 1356 of FIGURE 13C. When a determination is made that the schedule includes a conflict, scheduler 116 determines that one of the conflicting point control actions has a higher priority than the conflicting point control action (step 1372). As described previously with respect to FIGURE 12, the priority for performing one point control action over another can be based on the RD control modes and RD control periods for the two time control actions. For example, with reference to FIGURE 12, a first spot control action in a RD "active mode high" control period will have a higher priority than a second spot control action in a "start" control period moderately" of RD (that is, the run order "70" is greater than the run order "55" in the table of FIGURE 12). After scheduler 116 determines the highest priority point control action, scheduler 116 keeps this highest priority point control action in its original position in the schedule (step 1374). Scheduler 116 then moves the control action from the lowest priority point to a lower order of execution in the schedule, or alternatively removes the control action from the lowest priority point in the schedule (step 1376). For example, the control action of the lowest priority point can be moved to a position in the schedule that immediately follows the time when the control action of the high priority point has abandoned control of the point. Alternatively, in some situations or modalities, the control action of the lowest priority point can be completely erased from the programming. Upon completion of step 1376, scheduler 116 continues processing at step 1354 in FIGURE 13C. Demand Response Event History
[00094] Referring now to FIGURES 5 and 14, the history module 118 of the RDA 100 Application provides the user with a history of all DR events through the RDA 160 Client user interface. In the example of FIGURE 14 , the history of RD events received by the RDA Client 18 can be provided in the form of a color coded bar graph 1400 generated and displayed by the history module 118 via the RDA Client 160 user interface over time (by dates and times) on the x-axis and DR events (by mode) on the y-axis. The color-coded bar graph includes a different color for each possible DR mode. In particular, a horizontal green stripe 1402 is provided for a "normal" mode (ie no DR event), a horizontal yellow stripe 1404 is provided for a "moderate" mode, a horizontal red stripe 1406 is provided for a mode "high", and a horizontal purple stripe 1408 is provided for a "special" mode. This color coding arrangement gives viewers a quick way to readily determine the RD mode over several hours on the chart. A 1410 line connects all the points on the graph so that a bar graph results. Line 1410 is typically in normal mode stripe 1402, but extends above the normal mode stripe when an RD event occurs. The stripe and line extend to (ie, 1404, 1406, or 1408) provides viewers with a quick and easy way to see which DR events occurred at different dates and times. The RDA 100 Application allows viewers to modify the 1400 chart using the 1420 date range controls at the bottom of the 1400 chart. RDA Application Data Log
[00095] Referring now to FIGURES 5 and 15, the logging component 124 of the RDA 100 Application provides the user with a logging table 1500 of all actions taken by the RDA Client 18. This allows the operator to verify and review RDA 100 application activity as well as error detection. In the event of an error in the application of RDA 100, register table 1500 provides valuable information that can be used to help determine the source of the error in RDA client 18. In the example of FIGURE 15, register table 1500 includes a 1502 numeric list of actions taken, a 1504 type for each action, a 1506 timestamp for the action, a 1508 category for the action, and a general description of the 1510 action. Demand Response Monitoring in the Graphical User Interface
[00096] Referring now to FIGURE 16, in at least one embodiment of the RDA 100 application, the user is provided with a graphical user interface that includes a graphical representation of the building 600 or facility associated with the RDA client 18. graphical representation also includes a representation of all 644 energy consumption points in building 600, as well as any 646 energy production points associated with the building. Additionally, the graphical user interface is configured to provide the user with a demand response report for each DR event. Each demand response report includes data related to a selected DR event, which includes total building 1602 demand during DR event, 1604 actual energy production during DR event, net 1606 building demand during DR event. RD, 1608 expected demand during DR event, 1610 target demand reduction for RD event, and RD 1612 actual reduction during DR event. Demand response reporting information can be provided to the end user using any of several display methods. In the example of FIGURE 16, demand response reporting information is provided to the user using 1620 dial gauges. Each 1620 dial gauge includes a green portion that indicates the data as measured is within an acceptable range, and a red part indicating that the data as measured is outside an acceptable range. The 1620 display meters not only communicate information quickly and easily, but also provide an interesting visual display for the user, allowing the user to easily determine whether a building's response to a particular DR event was acceptable.
[00097] The above detailed description of one or more modalities of the automated demand response system has been presented in this document by way of example only and not by way of limitation. It will be recognized that there are advantages to certain individual features and functions described in this document that can be obtained without incorporating other features and functions described in this document. Furthermore, it will be recognized that various alternatives, modifications, variations, or improvements to the embodiments disclosed above and other features and functions, or alternatives thereto, may desirably be combined in many other embodiments, systems or applications. Unforeseen or unanticipated alternatives, modifications, variations, or improvements thereto may subsequently be made by persons skilled in the art which are also intended to be covered by the appended embodiments. Therefore, the spirit and scope of any attached embodiments should not be limited to the description of the modalities contained in this document.

权利要求:
Claims (11)
[0001]
1. Method for reducing an electrical load in an installation with a building automation system (22), characterized in that it comprises the steps of a) receiving a demand response message related to a demand response event through a computer connected to a network, the demand response message identifying at least one demand response mode for the demand response event, the demand response mode identifying different urgency or operating levels requested for the response event demand; b) determine at least one device of the building automation system (22) to be controlled during the demand response event based on an association between the at least one device and the at least one demand response mode for the response event the demand; c) generate a schedule of a plurality of control actions for the at least one device to execute in association with the demand response event, the control action schedule being generated based at least in part on a control period response to demand associated with the plurality of control actions; and e) sending control messages to the building automation system (22) to perform the control actions for the at least one device in accordance with the control action schedule for the demand response event; f) further comprising, before sending the control messages, determining (1354) whether there is at least one scheduling conflict for a first control action and a second control action from the control action scheduling, whereby execution of the first control action must cause the at least one device to operate differently from the second control action during the associated demand response control period; and g) determining whether at least one scheduling conflict occurs during the generation of the control action schedule, where generating the control action schedule includes preparing a preliminary schedule, determining whether there is at least one scheduling conflict in the preliminary schedule, and resolve the at least one scheduling conflict based on an execution priority order (1370-1376) associated with each of the first control action and the second control action.
[0002]
2. Method according to claim 1, characterized in that the control actions in the schedule are associated with a plurality of demand response control periods, the plurality of demand response control periods including a first demand-response control period that occurs before the at least one demand-response mode, a second demand-response control period that occurs during the at least one demand-response mode, and a third demand-response control period. demand response that occurs after at least one demand response mode.
[0003]
3. Method according to claim 2, characterized in that the plurality of demand-response control periods includes a fourth demand-response period that occurs before the demand-response event and a fifth demand-response period. demand response that occurs after the demand response event.
[0004]
4. Method according to claim 1, characterized in that the at least one demand response mode includes a first demand response mode and a second demand response mode each specified in the demand response message and associated with a respective start and end time, the at least one device being a single device, the method further comprising, before receiving the demand response message, associating the single device with a first of the predefined control actions for occur during a first control period starting after the end of the first demand response mode and with a second of the predefined control actions to occur during a second control period starting before the start of the second demand response mode; and after receiving the demand response message, determining that the first control action conflicts with the second control action based on the first control period overlapping the second control period.
[0005]
5. Method according to claim 4, characterized in that it comprises, even before receiving the demand response message, associating each demand response mode with a plurality of time references, each combination of response mode to the demand. demand and associated time reference being indicative of one of a plurality of demand response control periods, the first and second control periods each being one of the demand response control periods; assign a respective priority to each combination of demand response mode and associated time reference; and resolve the conflict between the first control action and the second control action based on the priority assigned to the combination of the first demand response mode and the associated time reference that is indicative of the first control period, and the priority assigned to the combination the second demand response mode and the associated time reference that is indicative of the second control period.
[0006]
6. Method according to claim 1, characterized in that the demand response message is received from an automated demand response server (14) on an automated demand response client (18) associated with the building automation system (22).
[0007]
7. System (10) for reducing the electrical load in a building, characterized in that it comprises a) a building automation system (SAP) (22) which includes a plurality of field panels (42) configured to distribute instructions for control for a plurality of devices in the building; b) an automated demand-response client (18) configured to receive a message concerning a demand-response event from an automated demand-response server (14), the message including information regarding the by minus one demand response mode for the demand response event, the demand response mode indicating different urgency or operating levels requested for the demand response event and the automated demand response client (18) including b1 ) a scheduler component (116) configured to generate a control action schedule for at least one device of the plurality of devices during the demand response event, the generation of the control action schedule being based at least in part on a demand-response control period associated with each of the control actions, and b2) an SAP communications component configured to distribute the control actions to the at least one device for the plurality of SAP field panels (42) according to the schedule; c) each demand-response control period being associated with the demand-response event or the at least one demand-response mode, and the scheduler is additionally configured to review the control action schedule to determine whether there is a scheduling conflict for control actions related to at least one device; and d) where, if there is a conflict in the schedule, the programmer is configured to resolve the conflict based on an execution priority order (1370-1376) for the control action, with the execution priority order (1370- 1376) is related to the demand response control period for the control action.
[0008]
8. System (10) according to claim 7, characterized in that the demand response control period for at least a first control action is a demand response control period that occurs during the event of demand response, the demand response control period for at least a second control action is a demand response control period that occurs before the demand response event, and the demand response control period for the minus a third control action is a demand-response control period that occurs after the demand-response event.
[0009]
9. System (10) according to claim 7, characterized in that the at least one demand response mode includes a first demand response mode and a second demand response mode each specified in the message of response to demand and associated with a respective start and end time; o at least one device is a single device; prior to receiving the demand response message, the automated demand response client (18) is configured to associate the single device with a first of the predefined control actions to occur during a first control period that begins after the end of the first demand-response mode and with a second of the predefined control actions to occur during a second control period that begins before the start of the second demand-response mode; and after receiving the demand response message, the automated demand response client (18) is configured to determine that the first control action conflicts with the second control action based on the first control period overlapping the second control period.
[0010]
10. Method according to claim 7, characterized in that the automated demand-response client (18) is configured to, before receiving the demand-response message, associate each demand-response mode with a plurality of time references, each combination of demand response mode and associated time reference being indicative of one of a plurality of demand response control periods, the first and second control periods each being one of the control periods response to demand; assign a respective priority to each combination of demand response mode and associated time reference; and resolve the conflict between the first control action and the second control action based on the priority assigned to the combination of the first demand response mode and the associated time reference that is indicative of the first control period, and the priority assigned to the combination the second demand response mode and the associated time reference that is indicative of the second control period.
[0011]
11. A computer-readable medium, characterized in that it contains instructions for controlling a computer system for generating instructions for controlling a building automation system (22) which includes a plurality of devices by performing one or more of the method steps of the method as defined in any one of claims 1 to 6.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112013032179B1|2021-05-04|method and system for reducing electrical load in a building automation facility and computer readable medium with instructions for controlling building automation

---

US20210149429A1|2021-05-20|Smart building manager

---

US9124132B2|2015-09-01|Automated demand response gateway

---

EP3101602B1|2018-09-12|Building energy consumption analysis system

---

US20130079931A1|2013-03-28|Method and system to monitor and control energy

---

US20120166115A1|2012-06-28|Platform, system and method for energy profiling

---

JP2010146268A|2010-07-01|Electric energy monitoring system, management server, and electric energy monitoring method

---

Sayed et al.2018|Building energy management systems |

---

Piette et al.2015|Costs to automate demand response-taxonomy and results from field studies and programs

---

Rassa et al.2019|Developing local energy markets: A holistic system approach

---

Piette et al.2021|Comparison of Actual Costs to Integrate Commercial Buildings with the Grid

---

CN209821878U|2019-12-20|Management system of building information

---

US20140032455A1|2014-01-30|Evolutionary Scheduling of Utility Consumers

---

US20220050430A1|2022-02-17|System and method for power arbitration of devices connected to a bus

---

Lu et al.2014|ESTCP Project EW-201255

---

BR112015004525B1|2021-12-07|METHOD FOR AN AUTOMATED DEMAND RESPONSE COMMUNICATION PORT, AUTOMATED DEMAND RESPONSE COMMUNICATION PORT AND COMPUTER READable MEDIA

同族专利:

---

公开号 | 公开日

---

CA2839382C|2019-09-24|

---

US20120323393A1|2012-12-20|

---

US20160118790A1|2016-04-28|

---

EP2721450A1|2014-04-23|

---

CN103748522A|2014-04-23|

---

KR101970029B1|2019-08-13|

---

BR112013032179A2|2017-12-05|

---

MX2013014927A|2014-02-11|

---

WO2012173883A1|2012-12-20|

---

US10110002B2|2018-10-23|

---

EP2721450B1|2018-03-07|

---

CA2839382A1|2012-12-20|

---

US9310786B2|2016-04-12|

---

CN103748522B|2016-12-21|

---

KR20140042852A|2014-04-07|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US5168170A|1989-09-07|1992-12-01|Lexington Power Management Corporation|Subscriber electric power load control system|

---

US5761083A|1992-03-25|1998-06-02|Brown, Jr.; Robert J.|Energy management and home automation system|

---

US5544036A|1992-03-25|1996-08-06|Brown, Jr.; Robert J.|Energy management and home automation system|

---

US5596502A|1994-11-14|1997-01-21|Sunoptech, Ltd.|Computer system including means for decision support scheduling|

---

US5640153A|1994-12-02|1997-06-17|Excel Energy Technologies, Ltd.|Energy utilization controller and control system and method|

---

CA2271448A1|1999-05-12|2000-11-12|Stuart Energy Systems Inc.|Energy distribution network|

---

US20020082748A1|2000-06-15|2002-06-27|Internet Energy Systems, Inc.|Utility monitoring and control systems|

---

US6778882B2|2001-05-10|2004-08-17|Siemens Westinghouse Power Corporation|Business management system and method for a deregulated electric power market with sharing of supply chain data|

---

US6732019B2|2001-05-10|2004-05-04|Siemens Westinghouse Power Corporation|Business management system and method for a deregulated electric power market using online diagnostic services|

---

US7280893B2|2001-05-10|2007-10-09|Siemens Power Generation, Inc.|Business management system and method for a deregulated electric power market|

---

US20030171851A1|2002-03-08|2003-09-11|Peter J. Brickfield|Automatic energy management and energy consumption reduction, especially in commercial and multi-building systems|

---

CA2515159A1|2003-02-07|2004-08-19|Power Measurement Ltd.|A method and system for calculating and distributing utility costs|

---

US20040213384A1|2003-04-23|2004-10-28|Alles Harold Gene|Remote access, control, and support of home automation system|

---

US20060009862A1|2004-06-28|2006-01-12|Raphael Imhof|Method and apparatus for accessing a building system model|

---

US7660649B1|2004-07-02|2010-02-09|Optimal Innovations Inc.|Resource management using calculated sensitivities|

---

CN100411270C|2005-01-14|2008-08-13|山东鲁维电子技术有限公司|Distributed visible intelligent electricity consumption control management system|

---

US8829799B2|2006-03-28|2014-09-09|Wireless Environment, Llc|Autonomous grid shifting lighting device|

---

WO2008039759A2|2006-09-25|2008-04-03|Intelligent Management Systems Corporation|System and method for resource management|

---

WO2008086114A2|2007-01-03|2008-07-17|Gridpoint, Inc.|Utility console for controlling energy resources|

---

US8805552B2|2007-08-28|2014-08-12|Causam Energy, Inc.|Method and apparatus for actively managing consumption of electric power over an electric power grid|

---

US8806239B2|2007-08-28|2014-08-12|Causam Energy, Inc.|System, method, and apparatus for actively managing consumption of electric power supplied by one or more electric power grid operators|

---

US8872379B2|2007-11-30|2014-10-28|Johnson Controls Technology Company|Efficient usage, storage, and sharing of energy in buildings, vehicles, and equipment|

---

US20100017045A1|2007-11-30|2010-01-21|Johnson Controls Technology Company|Electrical demand response using energy storage in vehicles and buildings|

---

US20090187499A1|2008-01-21|2009-07-23|David Mulder|System, Method and Computer Program Product for Providing Demand Response Functionality|

---

US7821156B2|2008-02-07|2010-10-26|International Business Machines Corporation|System and methods for scheduling power usage|

---

US20100076835A1|2008-05-27|2010-03-25|Lawrence Silverman|Variable incentive and virtual market system|

---

US20130035992A1|2008-05-27|2013-02-07|Kaspar Llc|Method and system for the more efficient utilization and conservation of energy and water resources|

---

US8639392B2|2008-09-29|2014-01-28|Battelle Memorial Institute|Electric power grid control using a market-based resource allocation system|

---

US9002761B2|2008-10-08|2015-04-07|Rey Montalvo|Method and system for automatically adapting end user power usage|

---

WO2010042200A1|2008-10-08|2010-04-15|Rey Montalvo|Method and system for fully automated energy curtailment|

---

CA2788839A1|2009-02-02|2011-08-05|Corporate Systems Engineering, Llc|Energy delivery control systems and methods|

---

US20100332373A1|2009-02-26|2010-12-30|Jason Crabtree|System and method for participation in energy-related markets|

---

US20110007824A1|2009-03-31|2011-01-13|Gridpoint, Inc.|System communication systems and methods for electric vehicle power management|

---

US9606520B2|2009-06-22|2017-03-28|Johnson Controls Technology Company|Automated fault detection and diagnostics in a building management system|

---

US8532839B2|2009-06-22|2013-09-10|Johnson Controls Technology Company|Systems and methods for statistical control and fault detection in a building management system|

---

US8731724B2|2009-06-22|2014-05-20|Johnson Controls Technology Company|Automated fault detection and diagnostics in a building management system|

---

US9753455B2|2009-06-22|2017-09-05|Johnson Controls Technology Company|Building management system with fault analysis|

---

US8788097B2|2009-06-22|2014-07-22|Johnson Controls Technology Company|Systems and methods for using rule-based fault detection in a building management system|

---

US8600556B2|2009-06-22|2013-12-03|Johnson Controls Technology Company|Smart building manager|

---

US20110006887A1|2009-07-13|2011-01-13|Kmc Controls, Inc.|Programmable Communicating Thermostat And System|

---

US8671167B2|2009-07-17|2014-03-11|Honeywell International Inc.|System for providing demand response services|

---

US9838255B2|2009-08-21|2017-12-05|Samsung Electronics Co., Ltd.|Mobile demand response energy management system with proximity control|

---

US8498749B2|2009-08-21|2013-07-30|Allure Energy, Inc.|Method for zone based energy management system with scalable map interface|

---

US9209652B2|2009-08-21|2015-12-08|Allure Energy, Inc.|Mobile device with scalable map interface for zone based energy management|

---

JP5752120B2|2009-07-20|2015-07-22|アリューア・エナジー・インコーポレイテッドＡｌｌｕｒｅ Ｅｎｅｒｇｙ， Ｉｎｃ．|Energy management system and method|

---

US9013059B2|2009-07-30|2015-04-21|Lutron Electronics Co., Inc.|Load control system having an energy savings mode|

---

US8417388B2|2009-07-30|2013-04-09|Lutron Electronics Co., Inc.|Load control system having an energy savings mode|

---

US8666555B2|2009-07-30|2014-03-04|Lutron Electronics Co., Inc.|Load control system having an energy savings mode|

---

US8901769B2|2009-07-30|2014-12-02|Lutron Electronics Co., Inc.|Load control system having an energy savings mode|

---

US8975778B2|2009-07-30|2015-03-10|Lutron Electronics Co., Inc.|Load control system providing manual override of an energy savings mode|

---

US8946924B2|2009-07-30|2015-02-03|Lutron Electronics Co., Inc.|Load control system that operates in an energy-savings mode when an electric vehicle charger is charging a vehicle|

---

US8866343B2|2009-07-30|2014-10-21|Lutron Electronics Co., Inc.|Dynamic keypad for controlling energy-savings modes of a load control system|

---

US8626344B2|2009-08-21|2014-01-07|Allure Energy, Inc.|Energy management system and method|

---

US8744638B2|2009-09-11|2014-06-03|General Electric Company|Method and system for demand response in a distribution network|

---

US10254745B2|2010-05-20|2019-04-09|Mechanical Software Technologies, Inc.|Computer-implemented automated design, modeling and manufacturing system for a project|

---

US8670875B2|2010-06-30|2014-03-11|Siemens Corporation|PLC function block for automated demand response integration|

---

US9148019B2|2010-12-06|2015-09-29|Sandia Corporation|Computing architecture for autonomous microgrids|

---

WO2012161804A1|2011-02-24|2012-11-29|Clean Urban Energy, Inc.|Integration of commercial building operations with electric system operations and markets|

---

US9244444B2|2011-03-07|2016-01-26|Callida Energy Llc|Systems and methods for optimizing energy and resource management for building systems|

---

US9544967B2|2011-04-15|2017-01-10|Wireless Environment, Llc|Lighting device capable of maintaining light intensity in demand response applications|

---

CA2870452C|2011-04-15|2020-03-10|Dominion Energy Technologies, Inc.|System and method for single and multi zonal optimization of utility services delivery and utilization|

---

US8862280B1|2011-06-13|2014-10-14|Gridpoint, Inc.|Dynamic load curtailment system and method|

---

US20120323382A1|2011-06-15|2012-12-20|Expanergy, Llc|Systems and methods to assess and optimize energy usage for a facility|

---

US20130110569A1|2011-10-27|2013-05-02|Mark Joseph Meyerhofer|Systems and methods to schedule demand response events|

---

US9638431B2|2011-12-08|2017-05-02|Energyhub, Inc.|Enhanced premises monitoring and/or control|

---

US10346931B2|2013-07-11|2019-07-09|Honeywell International Inc.|Arrangement for communicating demand response resource incentives|US8631411B1|2009-07-21|2014-01-14|The Research Foundation For The State University Of New York|Energy aware processing load distribution system and method|

---

US20130066482A1|2011-09-13|2013-03-14|Samsung Electronics Co., Ltd.|Apparatus and method for executing energy demand response process in an electrical power network|

---

US9082141B2|2011-10-27|2015-07-14|General Electric Company|Systems and methods to implement demand response events|

---

US8972071B2|2011-10-27|2015-03-03|General Electric Company|Systems and methods to predict a reduction of energy consumption|

---

US9125010B2|2011-10-27|2015-09-01|General Electric Company|Systems and methods to implement demand response events|

---

US20130110569A1|2011-10-27|2013-05-02|Mark Joseph Meyerhofer|Systems and methods to schedule demand response events|

---

WO2013088584A1|2011-12-14|2013-06-20|京セラ株式会社|Display terminal, power control system, and display method|

---

US9369305B1|2012-04-05|2016-06-14|IPKeys Technologies LLC|Short message service -enabled open automated demand responseserver and related communications systems and methods|

---

US9411323B2|2012-04-18|2016-08-09|Tekpea, Inc.|Home energy management system|

---

US10305699B2|2012-04-18|2019-05-28|Tekpea, Inc.|Device management system|

---

WO2014110109A1|2013-01-09|2014-07-17|Siemens Industry, Inc.|Electric load labeling post itemization based on analysis of power measurements at a single point|

---

US20150100171A1|2013-03-29|2015-04-09|Panasonic Intellectual Property Management Co., Ltd.|Load control method, load control device, and electrical load device|

---

US9946235B2|2013-08-06|2018-04-17|Honeywell International Inc.|Scheduling operation of groups of residential devices|

---

US10432753B2|2013-08-16|2019-10-01|Fujitsu Limited|Demand response event dissemination system and method|

---

EP3792706A1|2013-11-04|2021-03-17|Honeywell International Inc.|Methods and systems for providing improved service for building control systems|

---

US9568205B2|2014-01-20|2017-02-14|Emerson Electric Co.|Selectively connecting a climate control system controller with more than one destination server|

---

US10209692B2|2014-01-20|2019-02-19|Emerson Electric Co.|Selectively connecting a climate control system controller with more than one destination server|

---

US9953285B2|2014-01-22|2018-04-24|Fujitsu Limited|Residential and small and medium business demand response|

---

US10637240B2|2014-01-24|2020-04-28|Fujitsu Limited|Energy curtailment event implementation based on uncertainty of demand flexibility|

---

US20150213466A1|2014-01-24|2015-07-30|Fujitsu Limited|Demand response aggregation optimization|

---

US9817417B2|2014-03-31|2017-11-14|Energate Inc|Generating event anticipation parameters in advance of a demand response event|

---

CN105048447B|2014-04-24|2017-09-22|松下知识产权经营株式会社|integration demand control method and integration demand control device|

---

KR101508914B1|2014-07-03|2015-04-07|세종대학교산학협력단|DEVICE AND METHOD OF REDUCING AN OVERHEAD OF MESSAGE AND DELAY IN openADR|

---

US10591944B2|2014-12-03|2020-03-17|Ipkeys Power Partners Llc|Open automated demand responseserver|

---

JP1529042S|2014-12-15|2015-07-21|

---

USD781306S1|2015-01-27|2017-03-14|Johnson Controls Technology Company|Display screen or portion thereof with graphical user interface|

---

US10594700B2|2015-02-17|2020-03-17|Ademco Inc.|System of demand response provider control of network connected devices|

---

US10523008B2|2015-02-24|2019-12-31|Tesla, Inc.|Scalable hierarchical energy distribution grid utilizing homogeneous control logic|

---

WO2017026508A1|2015-08-12|2017-02-16|京セラ株式会社|Management server, management method, and management system|

---

US10615596B2|2015-09-30|2020-04-07|Siemens Aktiengesellschaft|Systems, methods and apparatus for an improved aggregation engine for a demand response management system|

---

JP6653153B2|2015-10-01|2020-02-26|株式会社日立製作所|Power demand adjustment plan management device|

---

US20170102681A1|2015-10-13|2017-04-13|Google Inc.|Coordinating energy use of disparately-controlled devices in the smart home based on near-term predicted hvac control trajectories|

---

US20170169344A1|2015-12-15|2017-06-15|The Trustees Of The University Of Pennsylvania|Methods, systems, and computer readable media for a data-driven demand responserecommender|

---

CN107272603B|2016-04-06|2019-11-12|西门子公司|Demand response control method and device|

---

KR101653797B1|2016-04-15|2016-09-09|스튜디오씨드코리아 주식회사|Method for prototyping Graphic User Interface and Apparatus thereof|

---

CN105955221B|2016-06-21|2020-07-24|北京百度网讯科技有限公司|Electrical equipment control method and device|

---

US10088192B2|2016-10-06|2018-10-02|Google Llc|Thermostat algorithms and architecture for efficient operation at low temperatures|

---

US10520903B2|2016-11-23|2019-12-31|Johnson Controls Technology Company|Building management system with priority array preview interface|

---

US10541556B2|2017-04-27|2020-01-21|Honeywell International Inc.|System and approach to integrate and manage diverse demand response specifications for multi-site enterprises|

---

US11239660B2|2017-05-10|2022-02-01|Korea Electronics Technology Institute|Demand response system and method for controlling devices to participate in demand response automatically|

---

US10879698B2|2017-11-30|2020-12-29|Abb Schweiz Ag|Systems and methods for performing building power management|

---

KR102068781B1|2018-03-07|2020-01-21|한전케이디엔 주식회사|Demand management provider system with openadr module for demand resource trading|

---

CN109633333B|2018-12-27|2021-07-23|国电南瑞科技股份有限公司|Provincial and above power grid various load shedding amount conflict detection and coordination check method|

---

KR102066671B1|2019-03-21|2020-01-15|김용서|Building controlling system and operation method thereof|

法律状态:
2018-12-11| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2019-11-05| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2021-02-09| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2021-05-04| B16A| Patent or certificate of addition of invention granted|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 08/06/2012, OBSERVADAS AS CONDICOES LEGAIS. |

优先权:

---

申请号 | 申请日 | 专利标题

---

US13/163,143|2011-06-17|

---

US13/163,143|US9310786B2|2011-06-17|2011-06-17|Automated demand response scheduling to reduce electrical loads|

---

PCT/US2012/041470|WO2012173883A1|2011-06-17|2012-06-08|Automated demand response system|

---