System for controlling a plurality of power-consuming devices

A system for controlling a plurality of power consuming devices is disclosed including a plurality of nodes, a gateway that communicates with the plurality of nodes, and a controller configured to send command signals to the nodes via the gateway. The controller associates each node with a region, each region representing a physical area and having a target profile associated therewith. The controller includes a command signal generation unit that determines command signals for a node based on the associated target profile, each node providing control signals to a corresponding power consuming device in response to a command signal received from the controller.

This application is a national application of International Application No. PCT/GB2017/050243 filed Feb. 1, 2017 pursuant to 35 U.S.C. § 363, wherein this application claims pursuant to 35 U.S.C. § 119(b) the benefit of the filing date of Feb. 1, 2016 of Great Britain Patent Application No. 1601768.3, the entire contents of each are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to a system for controlling a plurality of power consuming devices.

BACKGROUND AND PRIOR ART

There is an ongoing need to reduce energy consumption. One approach is the use of a building energy management system, in which a central system controls the operation of power consuming devices in the building according to defined criteria.

When installed into an existing building, retrofitting the required communications cabling can be costly. Alternative communication systems include power line communications (PLC) and wireless networking. PLC systems are usually low bandwidth; low power wireless communication systems such as those based on IEEE 802.15.4 (eg Zigbee™) deploy mesh network topologies to increase their working range at the cost of increased latency. Low bandwidth and/or high latency presents challenges for control systems that require live operating data such as device status, power consumption, etc.

Local users typically require the ability to override the central system. Managers at such sites often also require this ability in response to ad-hoc events such as unscheduled maintenance. Where several buildings are managed the control logic at each site tends to drift further from the original control logic over time. Benchmarking energy saving performance, eg between buildings, then becomes difficult as the control logic used may no longer be comparable.

In buildings where there are many devices to be controlled the control logic becomes cumbersome to maintain and update.

The present invention seeks to address at least some of the challenges with existing energy management systems, or to present a useful alternative.

SUMMARY OF THE INVENTION

In accordance with a first aspect of the invention there is provided a system for controlling a plurality of power consuming devices, comprising:a plurality of nodes;a gateway that communicates with the plurality of nodes;a controller configured to send command signals to said nodes via said gateway;wherein the controller associates each node with a region, each region representing a physical area and having a target profile associated therewith, controller including a command signal generation unit that determines command signals for a node based on the associated target profile, each node providing control signals to a corresponding power consuming device in response to a command signal received from the controller.

Preferably, the gateway receives status data from said nodes, the gateway buffering data from the nodes.

Preferably, one of the command signals is a request for node status data, the gateway configured to respond to the command signal using the buffered data, the command signal generation unit determining command signals for a node based on that node's status data.

Preferably, the gateway polls each node to request status data, the gateway configured to update the buffered data to indicate a node is offline if no status data is received from that node within a timeout period.

Preferably, each node is configured to transmit status data to the gateway in response to a change in a measured parameter.

Preferably, each node includes a power switch having an on state and an off state, wherein the state of the power switch is included in the status data.

Preferably, each node measures power used by the power consuming device, wherein power usage data is included in the status data.

Preferably, each node includes a fault event detector that causes the node to produce control signals in response to a default state command whenever the fault event detector determines a fault event has occurred.

Preferably, the fault event detector determines a fault event has occurred in response to a power failure to the node or a communication failure to the gateway.

Preferably, the default state command corresponds with 100% power to the power consuming device.

Preferably, at least one node includes a presence detection sensor providing presence data to the node, said presence data being included in the status data.

Preferably, at least one node is integral with its corresponding power consuming device.

Preferably, at least one power consuming device is a luminaire.

Preferably, the system includes at least one sensor measuring at least one physical parameter, wherein the controller is configured to receive measurement data from said at least one sensor.

Preferably, the controller associates at least one sensor with at least one region, the command signal generation unit determining command signals for a node based on measurement data from each sensor associated with the region with which that node is associated.

Preferably, a target profile represents power usage.

Preferably, a target profile represents light output, and at least one sensor in that region includes a lux sensor.

Preferably, a target profile is temperature, and at least one sensor in that region includes a temperature sensor.

Preferably, the command signal generation unit includes a rules engine.

Preferably, the system further comprises a data warehouse configured to request status data and measurement data from the controller and to store said status data and measurement in the warehouse.

Preferably, the data warehouse receives external data relating to a region.

Preferably, the data warehouse includes at least one preferred controller configuration including rules data used by the rules engine; each controller being associated with one of the preferred configurations in the data warehouse.

Preferably, the system further comprises a central processor that requests current configuration data from each controller.

Preferably, each controller is associated with a site identifier in the data warehouse.

Preferably, the central processor is configured to compare data in the data warehouse between controllers and sites.

Preferably, the central processor compares each controller's current rules data against preferred configuration data.

Preferably, the central processor compares power usage against rules data.

Preferably, the central processor produces a new preferred configuration which includes a current rule from a controller associated with that configuration and stores the new preferred configuration in the data warehouse.

Preferably, the central processor communicates the preferred configuration to each controller associated with that configuration along with a command to replace the controller's current configuration data with the preferred configuration data.

Preferably, the central processor includes a further command generator having a further rules engine, said central processor arranged to communicate commands produced by the further command generator to at least one controller.

DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1shows a system10for controlling a plurality of power consuming devices comprising a controller12, a gateway14and nodes16. Each node16has a corresponding power consuming device (not shown) to which the node16provides control signals as will be described in more detail below.

Referring now toFIG. 2, a functional block diagram of a node16is shown. The node16comprises a communications interface100, a command handler102and a reply generator104. The communications interface100receives command signals from the controller12via the gateway14and sends status data from the reply generator104to the gateway14. In the embodiment the interface100comprises an IEEE 802.15.4 interface such as ZigBee™. Whilst other interfaces can be used with the invention, this interface is preferred because its wireless mesh networking capability assists with retrofit installations.

The command handler102receives commands from the communications interface100and processes the commands. Commands may include an instruction to alter the state of an attached power consuming device, in which case the command is passed to a data interpreter106.

If the command is a request for status data, the command handler102passes the command to the reply generator104which reads status data from the data interpreter106and communicates the status data to the communications interface100for transmission to the gateway14.

The data interpreter106translates the commands containing a change of state for the device into corresponding I/O signal values and passes these to an I/O interface108. The I/O interface108produces control signals which are sent to the power consuming device to which the node16is connected. It is preferred that the I/O interface108includes multiple signal interfaces, including a 0 to 10 V control signal and a digital addressable lighting interface (DALI) interface. For example, a command to reduce power to 50% output may be translated to a value of 5V on a 0-10V control output. Other interfaces may be used according to the nature of the power consuming device.

The I/O interface108also includes a sensor input for receiving status data from a sensor. The sensor may be integrated in the power consuming device or it may be a separate sensor. Where the power consuming device is a luminaire, it is preferred that the sensor is a presence detector.

The node16further comprises a power switch in the form of a relay110configured to switch A/C power from a power input112to a power output114. In the embodiment, the power consuming device is attached to the power output114. A power monitor116measures the power consumption of the device attached to the power output114.

The relay110operates under control from the data interpreter106. Commands may be sent by the controller12to the node106to instruct the node to open or close the relay110. The state of the relay110, such as open/close or on/off, is included in the status data for the node16sent to the gateway14.

The data interpreter106receives sensor data from a sensor attached to the interface108and power consumption data from the power monitor106. In addition, the data interpreter106reads the current value of the control signals from the I/O interface108. Collectively, these form status data at the node16which is sent to the gateway14by the reply generator104.

The node16further includes a fault detector118configured to send commands to the command handler102when it detects the presence of a fault. The fault detector118detects whether power to the node16has been interrupted, such as by a brown-out or black-out detection circuit, or whether a communications fault has occurred based on an elapsed time since a command signal was received from the interface100. If either of these fault conditions is detected, the fault detector118sends a command to the command handler102. In one embodiment, the fault detector118sends a command to the command handler102to switch the power consuming device to 100% output; in an alternative arrangement the fault detector118is configured to switch the device to 0% output. The choice of which configuration to use will be determined by the nature of the power-consuming device. For instance in the situation where the device is a luminaire, the fault detector118is preferably configured to switch the device to full output power to ensure there is adequate lighting for safety. Alternatively, if the device is for instance a heating element, it may be preferable to have the device initially switched to 0% power in the event of a fault.

While the node16has been described as being a separate device from the power consuming device, in other embodiments the node may be integral with the power consuming device.

In some embodiments the data interpreter106may be configured to “push” status data from one or more sources. A preferred example occurs where the data interpreter106is configured to push status data whenever sensor data from an attached sensor changes state.

Referring now toFIG. 3, there is shown a functional block diagram of the gateway14. The gateway14comprises a first communication interface200in communication with the controller12and a second communication interface202in communication with nodes16. An outbound command handler204receives command signals from the controller12via the interface200. A command tracker206receives commands from the outbound command handler204and forwards the commands to the second interface202for transmission to the node identified in the command signal. The command tracker206monitors the time elapsed since a command signal was transmitted to a node and, in the absence of an response within a predefined time period, records the node as being off-line in a data buffer208.

An inbound data handler210receives status data from nodes16via the interface202. The data handler210notifies the command tracker206of receipt of data from a node so that the command tracker206can update its record of time elapsed since command signals were transmitted to a node and update the online/offline status of the node in the buffer208as necessary. The data handler210is further configured to store status data received from each node16in the data buffer208. Thus the gateway14stores in the data buffer208status data from all notes16with which it communicates. As new status data is received, the buffer208is updated accordingly.

In the embodiment, the command tracker206of the gateway14is configured to poll each node16periodically, which may range from several times per second to every few seconds according to the application, to request status data therefrom. The command tracker206then tracks whether responses are received by the data handler210from each node within a predefined response period, and stores this information in the buffer208. In this manner the gateway14maintains a record in the buffer208of which nodes are online and off-line together with the most recent status data received from each node.

The gateway14further comprises a reply generator212which is configured to transmit status data to the controller12via the interface200. The reply generator212obtains status data for a node from the buffer208rather than requesting it from the node to reduce the amount of traffic transmitted over the interface202and to ensure status data is always available for transmission to the controller12. The command handler204is configured to intercept command signals from the controller12requesting status data from a node and pass them to the reply generator212rather than to the command tracker206. Thus, requests from the controller12for status data are handled by the gateway14and are not communicated to nodes16, while other commands from the controller12are passed to the command tracker206for communication to nodes16. In embodiments where the communication between the gateway14and nodes16is via a wireless mesh-based networking the buffer arrangement of the gateway14enables status data to be provided in a timely manner to the controller12irrespective of any latency or offline status of a node due to the mesh nature of the networking.

Referring now toFIG. 4there are shown a functional block diagram of the controller12. The controller12includes a first communications interface302and a second communication interface304. The second communication interface304communicates with the gateway14. The controller further comprises a message handler306and a message generator308, a command generator310and a data handler312. A data store314is provided in the controller12.

The message handler306receives and interprets commands from a central processor as will be described hereinafter. The message generator308provides data to the central processor in response to commands received therefrom, and in some embodiments is arranged to push data to a data warehouse periodically such as every 5 minutes. The message generator308obtains such data from the data store314. The data store314of the embodiment has sufficient capacity to store five days of data to provide redundancy in the event of communication loss with the central processor or a data warehouse.

The command generator310includes a rules engine316which operates on a store of command rules318to generate commands to send to nodes. The command generator310sends commands to the second interface304for communication to nodes via the gateway14. Each command includes a node address. One such command includes a request for status data from a node.

In some embodiments the controller includes an interface such as a switch (not shown) to enable local override of rules engine316, typically for fixed time such as 45 mins although other time periods may be used. This provides a convenient override where necessary eg for local maintenance. In one implementation, such overrides are stored as high priority rules in the rule store318, whereby higher priority rules take precedence over lower priority rules. When a local override is activated, the controller12may push notification of the override to the data warehouse20. In some arrangements, the controller12may also push status data related to the override to the data warehouse; for example if the override relates to turning lights on, the controller12may also push lux measurement data to the warehouse. In some embodiments, the switches that provide an override signal to the controller12may be associated with a region, as described below, in which case the controller is configured to send commands to all nodes associated with that region in response so the override signal. In the case of maintenance, such commands would most commonly be to remove power to the power consuming devices by opening the relay in each node.

In some embodiments, the controller12may be responsive to override signals from other devices such as a fire alarm or intruder alarm. The rule store318may include automatic override rules triggered by a remote alarm system via an i/o interface. For instance, in the event of a fire alarm activating, an override rule may turn all lights on. An other example would be turning lights on in the regions where an impedance sensor has exceeded a threshold value to deter earth (ground) cable theft. In the event of an intruder alarm activating, an override rule may again turn all lights on, which may improve the quality of surveillance video such as CCTV.

A manager may be provided with permission to modify and create rules in the rule store318. The controller may keep a checksum in the rule store318which is incremented whenever a rule is created, modified or deleted, whereby the controller is configured to include the checksum when sending data to data warehouse or central processor. Including the checksum allows identification of rule changes by the central processor, and synchronisation of rules either from controller to data warehouse or from the data warehouse to the controller according to commands from the central processor. Such rule synchronisation may be across all controllers within a site, controllers in all sites within a region, or to all controllers on sites associated with an organisation. This arrangement provides a degree of flexibility while also allowing convenient synchronisation of rules for performance analysis.

The data handler312receives status data from the gateway14via the interface304and stores this data in the data store314. The data store further includes: region data defining at least one region, each region representing a physical area; target profile data defining a desired operating profile; device data defining operating characteristics of devices, and sensor data storing data received from sensors18. In a similar manner to that described above for the node16, the interface304may provide multiple external interfaces such as Ethernet and RS 485.

Examples of sensors18are shown inFIG. 1, including a lux sensor, a temperature sensor, and occupancy detector, a impedance or resistance meter, a power measuring sensor which may be a current monitor or a smart meter. Other forms of sensors are envisaged depending upon the application of the system. The sensors may be attached to a node16or they may be independently provided within a region and in communication with the controller12via the interface304. One form of sensor may be an I/O interface to other systems, such as an alarm system whereby the state of the alarm forms sensor data for the controller. Interfacing to other systems enables the controller to respond to external events, for instance in the event of an intruder alarm to issue commands to turn all lights to 100%. Where an alarm system has multiple sensors, eg door sensors and motion sensor in rooms, these may be associated with regions so that the controller may be provided with rules to turn on lighting within that region in response to an alarm.

The data store314also includes data associating each node with a region, each power-consuming device with a device data profile, each node with a device and each region with a target profile. The rules engine316utilises data in the data store314and association data along with rules318to generate commands. In one arrangement, the command generator310compares sensor data received from a node against the associated target profile for the region associated with the node to generate commands. For example if the sensor data included a lux sensor and the target profile included a desired illumination for a region, the command generator310compares the sensor data measuring the illumination in the region with the target profile and issues commands to increase or decrease the light output of luminaires attached to nodes to maintain the target profile. In one embodiment, the controller12is configured with rules that operate when the controller12issues commands to turn on or turn off the nodes in a region. For instance, the rules may review power consumption associated with that region prior to and after issuing the commands; if power consumption does not increase by a preconfigured minimum target an the controller12may issue an alert to advise the power consuming devices associated with that zone may not be operational. Additionally, the controller12may verify the state of each node's relay in the zone is in an expected state according to the commands sent, and issue and alert should the relay states not be correct.

In generating command signals, the command generated310also takes into account device data for the device attached to the node. For instance, a mercury vapour lamp may have a minimum time delay between turning off the lamp and turning it back on to allow a cooldown period.

Some of the power consuming devices may be heaters, one sensor may be a temperature sensor, and a target profile in the data store314for a region may represent a desired temperature profile. In this arrangement, the system enables control of heating.

Multiple regions may be defined which represent the same or overlapping physical areas to enable the system10to control multiple physical parameters such as light and temperature.

Within each region it is preferred that at least one occupancy detector is provided. Sensor data from the occupancy detector in combination with the rules engine316enables the controller12to vary the operation of power consuming devices according to whether people are present in the region. This allows for more efficient use of energy by the system10.

The system10shown inFIG. 1includes a single controller12and gateway14for clarity in the drawing. However, multiple controllers12each of which may have one or more gateways14are possible configurations of the system. Further, controllers12may be provided at multiple physical locations, called sites, so that the system may provide control across a number of physical locations.

The system10further includes a data warehouse20as shown inFIG. 1with which the controller12is in communication via a wide-area network such as the Internet. The message generator308of each controller12is arranged to transmit status data from nodes16and sensor data from sensors18to the data warehouse20. The data warehouse may also receive external data relating to a physical location where a controller12is located. Examples of external data include climate data and utility supplier data. Data received from each controller12is stored in the data warehouse associated with that controller. The data warehouse20may be configured using any suitable architecture such as star schema according to the Kimball data warehouse methodology; other configurations and methodologies may also be used.

The data warehouse20also includes at least one preferred controller configuration including rules data used by the rules engine316along with a checksum corresponding to that rules configuration. Each controller12is associated with one of the preferred configurations in the data warehouse20. Each controller is also associated with a site identifier in the data warehouse. Modifications to rules can be detected by comparing the checksum received from the controller with the checksum in the preferred controller configuration. Storing a preferred configuration in the data warehouse allows each controller to be returned to a known configuration by synchronisation of rules from the data warehouse to the controller.

A central processor22forms part of the system10. The central processor requests configuration data from each controller12. In response to the command request from the central processor or22, the message handler306in each controller12is configured to communicate command rules318, region data, target profile data and device data to the central process or22which stores this data in the data warehouse. In other implementations, the controller may send data directly to the data warehouse.

The central processor22includes an alert system which is shown inFIG. 5. The alert system includes an alert rule processor402configured to process a set of alert rules404. The alert rule processor402identifies any data in the data warehouse matching the alert rule criteria.

A state determining unit406is provided to determine why a node output has a certain state, in particular which rule in the command rules318is responsible for the present state of the output. The alert rule processor402may request the state determining unit406to determine the rule responsible for the state of a node output and receives a response from the unit406. In one arrangement the state determining unit is configured to return the highest priority rule currently applicable to the state of the output. This rule may not be the rule responsible for setting the status of the output, hence the determination may require analysing a data over a time window to make a determination. For instance, an hour ago a local user may have activated a local override to turn a light on. Half an hour later, the ambient light level may have dropped below a low light threshold, triggering a lower priority rule to turn the light on (which it already was, so no command may have been issued to the node). If the override was set to last 45 minutes, it would have expired so the override rule responsible for turning the light on is no longer responsible for the light's current on state.

An expectation handler408is also provided, which communicates with the alert rule processor402to indicate whether a future expectation defined in an alert rule has transpired. For example, an alert rule may indicate that 10 minutes after turning a light on, the lux reading in the region of the light will be above a predetermined value. In such a case, the alert rule processor402communicates the future expectation to the expectation handler408. The handler408will determine whether the expected condition was met after the defined time and provide an indication to the alert rule processor402. In some embodiments, the expectation handler408is also responsive to requests from users to provide indication why a node output has a given state. The indication may be provided via a user interface.

The alert rule processor402determines whether an alert is required based on the alert rule from the set of alert rules404, data in the data warehouse20, and if required also from the state determination unit406and/or expectation handler408. If an alert is required, the processor402notifies an alert dispatcher410.

The alert dispatcher410determines whether a command to a controller12is required in response to the alert. If a command is required, it is produced by the command generation unit412and sent to the controller12via a communications interface414. Alternatively, or in addition, a message to an actor is required in response to the alert. In this case, the message is produced by the message generation unit416and sent via the communications interface414. In some implementations, multiple messages may be issued in response to an alter to the same or multiple actors. Whether to issue command(s) and/or message(s) and the actors to receive the message(s) are stored in the alert rules404.

Providing the alert system in the central processor22enables alert rules based on events at more than one controller or site, or based on a comparison between sites or controllers. In addition, alert rules may also make use of information received at the data warehouse external to the controller12, such as weather or power supply status from the utility responsible for power at the site where the controller is situated.

The central processor22is also configured to compare and analyse data in the data warehouse between controllers and sites. This enables comparison of performance between different configurations of controllers in terms of energy efficiency and power utilisation and to assess any differences in the configurations which may be contributing to the performance difference. Such analysis enables optimisation of the controllers12across multiple sites to improve the overall energy efficiency of the system10. In one instance, the central processor22compares power usage against the command rules318used by each controller to identify whether any rules have been changed by site personnel which may be contributing to the difference in energy performance. The central processor22is arranged to communicate messages to a user corresponding to identified differences between a controller12and a preferred configuration associated with that controller. In one arrangement, the central processor includes a user interface for presenting such messages to the user.

Where a change in a rule is identified as increasing the energy efficiency of the system, the central processor22may produce a new preferred configuration including the current rules from a controller12associated with that configuration and stores the new preferred configuration in the data warehouse20. The central processor communicates the preferred configuration to each controller12associated with that configuration along with a command to replace the controller's current configuration data with the preferred configuration data. This enables synchronisation of rules between controllers associated with that configuration.