Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20040176877 A1
Publication typeApplication
Application numberUS 10/382,979
Publication dateSep 9, 2004
Filing dateMar 5, 2003
Priority dateMar 5, 2003
Also published asUS7650323, US20050288823, US20090105846, WO2004079461A2, WO2004079461A3
Publication number10382979, 382979, US 2004/0176877 A1, US 2004/176877 A1, US 20040176877 A1, US 20040176877A1, US 2004176877 A1, US 2004176877A1, US-A1-20040176877, US-A1-2004176877, US2004/0176877A1, US2004/176877A1, US20040176877 A1, US20040176877A1, US2004176877 A1, US2004176877A1
InventorsScott Hesse, William Nicolay, Hugh Adamson
Original AssigneeScott Hesse, William Nicolay, Adamson Hugh P.
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Building automation system and method
US 20040176877 A1
Abstract
Building automation system and method. According to one embodiment of the invention, building automation system may comprise a controller area network (CAN) bus. At least one control device is operatively associated with the CAN bus, the at least one control device issuing a signal over the CAN bus. At least one controlled device is operatively associated with the CAN bus, the at least one controlled device responding to the signal.
Images(5)
Previous page
Next page
Claims(31)
What is claimed is:
1. A building automation system, comprising:
a controller area network (CAN) bus for a building;
at least one control device operatively associated with said CAN bus, said at least one control device issuing a signal over said CAN bus; and
at least one controlled device operatively associated with said CAN bus, said at least one controlled device responding to said signal.
2. The building automation system of claim 1, further comprising a controller operatively associated with said CAN bus, said controller generating at least one instruction corresponding to said signal, said controller issuing said instruction over said CAN bus for said at least one controlled device.
3. The building automation system of claim 2, wherein the controller is a central controller.
4. The building automation system of claim 2, wherein the controller is a distributed controller.
5. The building automation system of claim 1, wherein said at least one control device issues said signal by broadcasting said signal over said CAN bus.
6. The building automation system of claim 1, wherein said CAN bus comprises separate busses operatively associated with one another.
7. The building automation system of claim 6, wherein each of said separate busses is a dedicated bus.
8. The building automation system of claim 1, further comprising at least one repeater operatively associated with said CAN bus.
9. The building automation system of claim 1, further comprising an external link from said CAN bus, said external link providing access to said CAN bus.
10. A building automation system, comprising:
a controller area network (CAN) bus for a building;
at least one control device operatively associated with said CAN bus, said at least one control device receiving input;
at least one distributed controller operatively associated with said at least one control device, said at least one controller generating a signal corresponding to said input received by said at least one control device;
at least one controlled device operatively associated with said CAN bus, said at least one controlled device responding to said signal.
11. The building automation system of claim 10, further comprising at least another distributed controller operatively associated with said at least one controlled device.
12. The building automation system of claim 10, wherein said signal comprises an instruction.
13. The building automation system of claim 10, wherein said signal comprises an address, said address identifying said at least one controlled device.
14. The building automation system of claim 10, wherein said at least one controlled device comprises a device identification.
15. The building automation system of claim 14, wherein said at least one controlled device comprises a dynamic address corresponding to said device identification.
16. The building automation system of claim 10, further comprising an external link.
17. The building automation system of claim 10, further comprising at least one map, said at least one map comprising a status of devices on said CAN bus.
18. A building automation system, comprising:
a controller area network (CAN) bus;
at least one control device operatively associated with said CAN bus, said at least one control device issuing a signal corresponding to input received at said at least one control device;
at least one controlled device operatively associated with said CAN bus, said at least one controlled device receiving said signal;
at least one distributed controller operatively associated with said at least one controlled device, said at least one distributed controller generating an instruction corresponding to said signal received by said at least one controlled device, said at least one controlled device responding to said signal based on said instruction generated by said at least one controller.
19. The building automation system of claim 18, further comprising at least another distributed controller operatively associated with said at least one control device.
20. The building automation system of claim 18, wherein said signal comprises an address field, said address field having an address for identifying said at least one control device.
21. The building automation system of claim 18, wherein said at least one control device and said at least one controlled device each comprise unique device identifications.
22. The building automation system of claim 21, wherein said at least one control device and said at least one controlled device each comprise dynamic addresses corresponding to said unique device identifications.
23. The building automation system of claim 18, further comprising at least one map, said at least one map comprising a status of devices on said CAN bus.
24. The building automation system of claim 18, wherein the at least one control device is operatively associated with said CAN bus via a remote link.
25. The building automation system of claim 18, wherein the at least one controlled device is operatively associated with said CAN bus via a remote link.
26. A building automation method, comprising:
receiving input at a control device for a building;
generating a signal corresponding to the input;
issuing the signal over a controller area network (CAN) bus; and
responding to the signal at a controlled device for the building.
27. The method of claim 26, further comprising generating an instruction corresponding to the input received at the control device for the building, the signal having the instruction.
28. The method of claim 26, further comprising identifying the control device in the signal.
29. The method of claim 26, further comprising identifying the controlled device in the signal.
30. The method of claim 26, further comprising issuing an acknowledgement from the controlled device over the CAN bus for the control device.
31. The method of claim 26, further comprising automatically determining the status of the control device and the controlled device.
Description
FIELD OF THE INVENTION

[0001] The invention generally pertains to building automation, and more specifically, to building automation systems and methods.

BACKGROUND OF THE INVENTION

[0002] The ability to control one or more devices in a building (e.g., lighting, heating, air conditioning, security systems) based on one or more parameters (e.g., time, temperature, user preference) is known as building automation. Building automation may be implemented in any of a number of different types of buildings, including homes, offices, restaurants, stores, theaters, and hotels, to name only a few.

[0003] Building automation systems operate by issuing commands from a control panel (e.g., a keypad) to an output device (e.g., a lamp control). Inexpensive building automation systems are available which use the existing electrical wiring in the building for issuing commands to the output device. The control panel and output device are each plugged into electrical outlets in the home and the control panel issues commands via the electrical wiring in the home. However, the commands may be distorted or lost due to “noise” in the electrical wiring. In addition, such systems are limited to relatively few output devices.

[0004] Inexpensive building automation systems are also available in which the control panel issues radio frequency (RF) commands to the output devices. However, RF transmission is typically limited in range (e.g., by government regulation) and is subject to interference (e.g., from other RF devices).

[0005] Other building automation systems are available which use an RS 232 architecture to issue commands from the control panel to the output devices. The RS 232 architecture allows more reliable data exchange between the control panel and the output devices. However, the control panel must be directly connected to each of the output devices to which the control panel issues commands (i.e., a point-to-point or so-called “hub-and-spoke” arrangement). Such an arrangement can only be used for short runs and is wiring intensive, which can be expensive to install and maintain. In addition, the RS 232 architecture does not provide for error-handling.

SUMMARY OF THE INVENTION

[0006] A building automation system according to one embodiment of the invention may comprise a controller area network (CAN) bus for a building. At least one control device is operatively associated with the CAN bus, the at least one control device issuing a signal over the CAN bus. At least one controlled device is operatively associated with the CAN bus, the at least one controlled device responding to the signal.

[0007] An embodiment of a building automation method may comprise: receiving input at a control device for a building; generating a signal corresponding to the input; issuing the signal over a controller area network (CAN) bus; and responding to the signal at a controlled device for the building.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Illustrative and presently preferred embodiments of the invention are shown in the drawings, in which:

[0009]FIG. 1 is a high-level schematic diagram of one embodiment of a building automation system;

[0010]FIG. 2 is an illustration of one embodiment of an instruction table for use with the building automation system shown in FIG. 1;

[0011]FIG. 3 is a high-level schematic diagram of another embodiment of a building automation system;

[0012]FIG. 4 is a high-level schematic diagram showing one embodiment of distributed controllers for the building automation system of FIG. 3;

[0013]FIG. 5 is an illustration of one embodiment of a signal which may be issued over the CAN bus of the building automation system.

DESCRIPTION OF THE PREFERRED EMBODIMENT

[0014] Embodiments of a building automation system 100 are shown and described herein according to the teachings of the present invention. The building automation system 100 may be used to automate various functions in a home or other building (not shown). Exemplary functions may include lighting, heating, air conditioning, audio/visual output, operating window coverings to open/close, and security, to name only a few.

[0015] The embodiment of building automation system 100 shown in FIG. 1 may comprise one or more control devices 110-113 (e.g., a keypad) operatively associated with one or more controlled devices 120-124 (e.g., a triac board). Control devices 110-113 (hereinafter, generally referred to as control device 110) issue commands, which in turn instruct the controlled devices 120-124 (hereinafter, generally referred to as controlled device 120) to perform a function. By way of example, when a homeowner (or more generally, a user) presses a key on the keypad (e.g., control device 110), the central lighting in the room may illuminate to a predetermined intensity (e.g., 50%) and perimeter lighting in the room may be turned on (e.g., at 100% intensity) to illuminate artwork hanging on the walls.

[0016] It should be understood that the foregoing example is provided in order to better understand one environment in which the building automation system 100 of the present invention may be used. Of course the building automation system of the present invention may comprise any of a wide range of other types and configurations of control devices 110 and controlled devices 120, and various functions beyond lighting a room, which are now known or that may be developed in the future. The particular types and configurations of control devices 110 and controlled devices 120 may depend in part on design considerations, which can be readily defined and implemented by one having ordinary skill in the art after having become familiar with the teachings of the invention.

[0017] According to preferred embodiments of the invention, control device 110 and controlled device 120 are operatively associated with a control area network (CAN) bus 130. The CAN bus 130 may comprise a two-wire differential serial data bus. The CAN bus 130 is capable of high-speed data transmission (about 1 Megabits per second (Mbits/s)) over a distance of about 40 meters (m), and can be extended to about 10,000 meters at transmission speeds of about 5 kilobits per second (kbits/s). It is also a robust bus and can be operated in noisy electrical environments while maintaining the integrity of the data.

[0018] The building automation system 100 of the present invention is not limited to any particular configuration or number of devices, and may comprise as many as 16,000 or more devices linked over extended runs throughout the building. The building automation system 100 also preferably comprises error handling and bus arbitration, enhancing its performance. The speed with which a number of (i.e., one or more) devices may send and receive signals over a single CAN bus is particularly advantageous for building automation (e.g., lights can be turned on and off immediately without recognizable delay). In addition, more than one CAN bus 130, 131 may be combined to extend the functionality of the building automation system 100. For example, a general purpose CAN bus may be provided for lighting and another CAN bus may be dedicated to the security system. The building automation system 100 may also be modified for different devices and/or functions, even after the initial installation, allowing the building automation system to be tailored to the user's preferences.

[0019] Having briefly described a building automation system according to an embodiment of the invention, as well as some of the features and advantages of the invention, embodiments of the invention will now be described in detail.

[0020] According to one embodiment of the invention, building automation system 100 may comprise a CAN bus 130, as shown in FIG. 1. At least one control device 110 may be operatively associated with the CAN bus 130, and at least one controlled device 120 may be operatively associated with the CAN bus 130. Suitable interfaces (not shown) may be provided for control device 110 and controlled device 120 for issuing and receiving signals over the CAN bus 130. Such interfaces can be readily provided by one skilled in the art after having become familiar with the teachings of the present invention.

[0021] As mentioned above, the CAN bus 130 may comprise a two-wire differential serial data bus. The CAN specification is currently available as version 1.0 and 2.0 and is published by the International Standards Organization (ISO) as standards 11898 (high-speed) and 11519 (low-speed). The CAN specification defines communication services and protocols for the CAN bus, in particular, the physical layer and the data link layer for communication over the CAN bus. Bus arbitration and error management is also described. Of course the invention is not limited to any particular version and it is intended that other specifications for the CAN bus now known or later developed are also contemplated as being within the scope of the invention.

[0022] Control device 110 may be any suitable device (e.g., a keypad, sensor, etc.) which is generally configured to receive input and generate a signal based on the received input. By way of example, control device 110 may be a keypad or keyboard. When the user presses a key (or sequence of keys) on the keypad, one or more signals may be generated that are representative of the key(s) that were pressed. The signal(s), in turn, correspond to a predetermined function (e.g., dim central lighting to 50%, activate security system), as will be described in more detail below.

[0023] Of course control device 110 may be any suitable device and is not limited to a keypad or keyboard. Examples of control devices 110 also include, but are not limited to, graphical user interfaces (GUI), personal computers (PC), remote control devices, security sensors, temperature sensors, light sensors, and timers.

[0024] Controlled device 120 may be any suitable device which is generally configured to perform one or more functions in response to a signal issued by control device 110. By way of example, controlled device 120 may be a controllable alternating current (AC) switch and associated processing hardware and/or software, such as a triac board. When the triac board receives an instruction to dim the main lighting, the triac board causes the main lighting to dim (e.g., to 50% intensity). Preferably, the controlled device 120 receives the instruction over the CAN bus 130, as will be described in more detail below. In other embodiments, controlled device 120 may also receive input from sources other than the CAN bus 130.

[0025] Of course it is understood that a single device need not be dedicated as a control device 110, or alternatively, as a controlled device 120. A device which performs the functions of both a control device 110 and a controlled device 120 may also be used according to the teachings of the invention. Such a device is represented in the high-level schematic of FIG. 1 as separate devices 110 and 120. That is, when the device performs the functions of a control device, it is represented in FIG. 1 as control device 110. When the device performs the functions of a controlled device, it is represented in FIG. 1 as controlled device 120.

[0026] It is also understood that control device 110 and controlled device 120 may be operatively associated with the CAN bus 130 in any suitable manner, including by permanent, removable, or remote link. By way of example, control device 110 and/or controlled device 120 may be permanently linked to the CAN bus 130 by a hard-wire connection. Alternativley, control device 110 and/or controlled device 120 may be removably linked to the CAN bus 130 by a suitable “plug-type” connection. Control device 110 and/or controlled device 120 may also be remotely linked to the CAN bus 130, for example via an RF link.

[0027] Building automation system 100 may also comprise a central controller 140 operatively associated with the CAN bus 130 as shown in FIG. 1. Central controller 140 may be linked to the CAN bus 130 in any suitable manner, such as was described above for control device 110 and controlled device 120.

[0028] Central controller 140 may be any suitable device generally configured to receive a signal from control device 110 over the CAN bus 130, and in turn, to issue a signal with a corresponding instruction over the CAN bus 130 for controlled device 120. In one embodiment, central controller 140 may be reprogrammable, i.e., capable of executing computer-readable program code (including but not limited to scripts), which can be changed to reprogram the central controller 140. By way of example, central controller 140 may comprise one or more personal computers or server computers, microprocessors, programmable logic devices (PLA) such as a field programmable gate array (FPGA) or application-specific integrated circuit (ASIC), to name only a few.

[0029] Before continuing, it should be noted that the term “central” in “central controller 140” is used to describe the interoperability with more than one of the control devices 110 and controlled devices 120. It is not intended to limit the physical location of the central controller with respect to the CAN bus 130 (or subnets 131) or the devices on the CAN bus 130.

[0030] It should also be noted that central controller 140 may be provided with various ancillary devices, for example, power supplies, electronic controls, input/output (I/O) devices, computer readable storage media, etc. Such ancillary devices are well-understood and therefore are not shown or described herein as further description is not needed for a full understanding of, or to practice the invention.

[0031] Preferably, the central controller 140 also performs error checking and bus arbitration functions. Error checking and bus arbitration is defined by the CAN specification, currently in versions 1.0 and 2.0. These functions may be provided to enhance performance of the building automation system 100 by reducing the occurrence of corrupt or lost signals on the CAN bus 130.

[0032] As mentioned briefly above, central controller 140 is configured to receive signals over the CAN bus from control device 110, and issue signals with corresponding instructions over the CAN bus for controlled device 120. Central controller 140 may access the instruction from an instruction table, such as the exemplary instruction table 150 shown in FIG. 2.

[0033] Instruction table 150 may be defined based on various parameters, such as the needs and desires of the building occupant. Although instruction table 150 may be generic (i.e., applicable to one or more predefined configurations of the building automation system 100), it is preferably custom or tailored to each building automation system 100 and is therefore defined once the configuration of a particular building automation system 100 is known. In addition, instruction table 150 preferably may be reconfigured based on the changing needs and/or desires of the building occupants.

[0034] In one embodiment, the instruction table 150 may comprise signal data 200 and instructions 210. Signal data 200 corresponds to the input received by the central controller 140. In one embodiment, signal data 200 comprises the identity of the control device (Device ID) and the type of input received at the control device (Input ID). In this embodiment, the instructions 210 are functions that the controlled device 120 may perform, and preferably correspond to the signal data 200. For example, in FIG. 2, signal data 200 may comprise Device ID=Device 1 and Input ID=Key 1. The instructions corresponding to this signal data 200 are “Main Lighting 50%” and “Perimeter Lighting ON”.

[0035] It is understood that the instruction table 150 may be defined in any suitable manner. For example, instruction table 150 may be defined as a code-driven table. It is understood, however, that instruction table 150 is not limited to any particular format and the embodiment shown in FIG. 2 is merely exemplary for purposes of illustrating its use in the present invention.

[0036] The instruction table 150 is preferably operatively associated with the central controller 140 for use with the building automation system 100. For example, the instruction table 150 may be stored on suitable computer readable storage media accessible by the central controller 140.

[0037] According to preferred embodiments, the instruction table 150 may be modified or replaced. Modifying or replacing the instruction table 150 is particularly advantageous when one or more control devices 110 and/or controlled devices 120 are added or removed from the building automation system 100. Modifying or replacing the instruction table 150 may also be used to change one or more parameters for control device 110 (e.g., defining a new key) and/or controlled device 120 (e.g., changing the lighting intensity). For example, when the building changes occupancy, the instruction table 150 may be changed to reflect needs and/or desires of the new occupants.

[0038] Optionally, building automation system 100 may comprise an external link 160. In one embodiment, external link 160 may comprise a link from central controller 140 to another network such as the Internet via an Internet service provider (ISP). Preferably, external link 160 may be used to import/export the instruction table 150 (e.g., at installation or for changes).

[0039] External link 160 may also be used to troubleshoot the building automation system 100. For example, when an error occurs on the CAN bus 130, the central controller 140 may generate an error message which may be transmitted to the building owner and/or a monitoring service (e.g., via email, pager alert, etc.).

[0040] Of course, it is understood that the external link 160 is not limited to an ISP link. In other embodiments, the external link 160 may be via a local area network (LAN), a wide area network (WAN), an Intranet, a telephony link. In addition, external link 160 may connect to any suitable external device, such as to a laptop computer, personal digital assistant (PDA), pager, facsimile machine, or mobile phone, to name only a few. In addition, external link 160 may comprise a temporary connection for use by a service technician. For example, the external link 160 may comprise a link suitable for connecting a laptop computer to the building automation system 100.

[0041] Building automation system 100 may also comprise an optional repeater 170, as shown in FIG. 1 provided in-line on the CAN bus 130. Repeater 170 may be used to extend the physical length of the CAN bus 130, and/or increase the number of devices that can be provided on the CAN bus 130. For example, repeater 170 may amplify signals and/or “clean” (e.g., improve the signal to noise ratio) the signals issued over CAN bus 130.

[0042] Building automation system 100 may also comprise one or more additional busses 131. Preferably, the optional bus 131 is also a CAN bus. In one embodiment, building automation system 100 may comprise dedicated busses 130, 131. Dedicated busses 130, 131 may be categorized by type of device, area of the building (e.g., first floor, bedrooms), or any other suitable category. For example, a dedicated CAN bus 130 may be provided for all of the lighting devices and another dedicated CAN bus 131 may be provided for all of the security devices. Accordingly, a failure in one CAN bus 130 preferably does not affect operation of the other CAN bus 131.

[0043] Building automation system 100 may be operated as follows according to one embodiment of the invention. Control device 110 and/or controlled device 120 may be configured during manufacture, during installation, or when reconfiguring the building automation system 100. Instruction table 150 is provided for use by the controller 140. Instruction table 150 is also defined for the building automation system 100.

[0044] In any event, once the building automation system 100 is configured and ready for use, control device 110 may be operated to receive input (e.g., from the user or other source), and generate signals based on the received input. By way of example, when the user enters input to control device 110 (e.g., by pressing one or more keys on a keypad), control device 110 may issue signal(s) that are representative of the input (e.g., the keys that were pressed). As an illustration, when the user presses the key labeled “Illuminate Artwork”, control device 110 issues signal(s) corresponding to one or more functions to illuminate the artwork in the room. These signals are issued over the CAN bus 130 for one or more controlled devices 120.

[0045] In one embodiment, the signal(s) are broadcast by the control device 110 over the CAN bus 130. That is, signals are received by each of the devices (110, 120, 140) on the CAN bus 130. Each device (110, 120, 140) determines whether it should respond to the signal. For example, the device should respond where a packet identification in the signal is related to the device function(s). It is noted that more than one device may respond to the signal. If the device determines that it should not respond, the device does nothing (i.e., the device “ignores” the signal).

[0046] Preferably in this embodiment, only the central controller 140 responds to signal(s) from control device 110. Although each of the devices on the CAN bus 130 receive the signal from control device 110, none of the other devices respond.

[0047] The central controller 140 receives the signal from control device 110. Central controller 140 responds by accessing the instruction table 150 and issuing an instruction based on the signal. For example, when the signal data includes Device ID of “Device 1” and Input ID of “Key 2”, the corresponding instructions according to the instruction table 150 in FIG. 2 are “Main Lighting 50%” and “Perimeter Lighting ON”. The central controller 140 issues these instructions over the CAN bus 130.

[0048] In one embodiment, the central controller 140 broadcasts a signal comprising the instructions over the CAN bus 130. The broadcast signal is received by each of the devices (110, 120, 140) on the CAN bus 130, and each device (110, 120, 140) determines whether it can respond to the instructions. If the device (110, 120, 140) determines that it cannot respond, it ignores the instructions.

[0049] In the above example, one of the devices (e.g., controlled device 122 in FIG. 1) may be a triac board for the main lighting circuit, and another of the devices (e.g., controlled device 123 in FIG. 1) may be a single-pull single-throw switching board (e.g., a switch with associated processing hardware and software) for the recessed perimeter lighting. Accordingly, controlled device 122 responds to the instruction “Main Lighting 50%” by dimming the main lighting circuit to 50%, and controlled device 123 responds to the instruction “Perimeter Lighting ON” by turning on the recessed perimeter lighting. The central lighting in the room dims and the recessed perimeter lighting turns on, illuminating artwork hanging on the walls in the room.

[0050] Of course it is understood that the above example is merely illustrative of one embodiment of the invention. The scope of the invention is not limited to this example. Indeed, the building automation system 100 of the present invention is also well-suited for performing more elaborate functions, now know or that may be later developed, as will be readily appreciated by one skilled in the art after having become familiar with the teachings of the present invention.

[0051] Another embodiment of the building automation system 300 is shown in FIG. 3 comprising at least one control device 310 and at least one controlled device 320 linked over CAN bus 330. It is noted that 300-series reference numbers are used to refer to the like elements shown in FIG. 1, which were described above with respect to embodiment 100.

[0052] The central controller 140 shown and described above is optional in embodiment 300, and may not be provided. The building automation system 300 comprises distributed controller(s) 400 (see FIG. 4) operativley associated with each control device 310. Alternatively, distributed controller(s) 400 may be operatively associated with each controlled device 320. In another embodiment, distributed controllers 400 may be operatively associated both with each control device 310 and with each controlled device 320.

[0053] Distributed controller 400 may be any suitable device configured to process signals 500 (see FIG. 5). In one embodiment, distributed controller 400 may be reprogrammable, i.e., capable of executing computer-readable program code (including but not limited to scripts), which can be changed to reprogram the distributed controller 400. One or more of the distributed controllers 400 may also perform error checking and bus arbitration functions for the CAN bus 330. Exemplary distributed controllers 400 may comprise one or more microprocessors, PLAs (e.g., FPGA, ASIC), etc. It should be noted that distributed controllers 400 may be operatively associated with control device 310 and/or controlled device 320 in any suitable manner. Preferably, distributed controllers 400 are provided at, and are directly linked to control device 310 and/or controlled device 320 (e.g., as part of the same computer board).

[0054] Advantageously, only the device operatively associated with a failed or otherwise offline distributed controller 400 is affected by such failure (or by being offline). Other devices 310, 320 of the building automation system 300 may continue in operation even though one or more of the distributed controllers 400 is no longer operational. Further advantages will be described below with regard to various embodiments and will also become apparent to one skilled in the art after having become familiar with the teachings of the invention.

[0055] In operation, distributed controller 400 preferably generates signals 500 comprising signal data in one or more fields 510-540, as shown according to one embodiment in FIG. 5. For example, distributed controller 400 may generate a signal 500 comprising an instruction (e.g., field 520). That is, when control device 310 receives input, distributed controller 400 may use instruction table 410 to generate a signal 500 comprising corresponding instruction(s) for controlled device 320. Likewise, distributed controller 400 may perform any number of functions for the controlled device 320. In one embodiment, distributed controller 400 generates instructions for controlled device 320 based on signals that are received over the CAN bus 330.

[0056] According to embodiments of building automation system 300 (FIG. 3), control device 310 and controlled device 320 may each comprise a device address 430 (FIG. 4). Preferably, each device address 430 is unique to the device 310, 320. For example, device addresses 430 may be assigned to the devices 310, 320 as unique part numbers, although it is noted that the part number need not be numerical. The device address 430 may be provided with each device 310, 320 in a suitable memory, although other embodiments are also contemplated as being within the scope of the invention. In any event, no other device 310, 320, according to this embodiment, has the same device address 430, thereby reducing the likelihood that the device 310, 320 is misidentified. For example, a triac board is not misidentified on the CAN bus 330 as a security board (e.g., activating an alarm when the user intends to turn on the lights).

[0057] It is understood that other embodiments are also contemplated as being within the scope of the invention. In another embodiment, the device address 430 may be unique to a category of devices. For example, each triac board may have the same device address 430, which is different from the device address 430 used to identify electric motor controls. Yet other embodiments are also contemplated as being within the scope of the invention and will become apparent to those skilled in the art after having become familiar with the teachings of the invention.

[0058] The address of the devices 310, 320 (FIG. 3) may be provided in the signals 500 (FIG. 5), for example, in an address field 510. Accordingly, the signals 500 may be addressed to specific control devices 310 and/or controlled devices 320, allowing so called “peer-to-peer” communication over the CAN bus 330 even though the signal 500 is broadcast to each of the devices on the CAN bus 330. Addressing also allows particular device(s) on the CAN bus 330 to be reset without having to reset all of the devices on the CAN bus 330 (i.e., only the device(s) identified in the address field 510 perform a reset instruction in field 520).

[0059] In operation, the distributed controller 400 processes the address field 510 of the signal 500 to determine whether it is addressed to the device 310, 320. By way of example, the signal 500 may be broadcast over the CAN bus 330 to each of the devices 310, 320, as discussed above. The distributed controllers 400 read the address in the address field 510 and determine whether it corresponds to the device address 430. If the address in the address field 510 does not correspond to the device address 430, the device 310, 320 does not respond. Preferably, the controller 400 stops processing the signal 500, thereby conserving processing power and increasing the efficiency of the building automation system 300. If the address in the address field 510 corresponds to the device address 430, the controller 400 continues processing the signal 500. Again, it is noted that more than one device may respond to a signal.

[0060] Other embodiments are also contemplated as being within the scope of the invention. A signal 500 may be addressed to all of the devices on the CAN bus 330 (e.g., by setting the address field to null). For example, a signal 500 may be addressed to all of the devices so that the user can readily reset all of the devices on the CAN bus 330 after a power outage. Likewise, a signal 500 may be addressed to groups of devices by including a group identification in the address field 510 or another field (e.g., Field n 540). For example, a signal 500 may be addressed to all of the devices, or particular types of devices (e.g., the lights) or categories of devices (e.g., outdoor lights) so that the user can readily shut all of those devices (e.g., by pressing a single key).

[0061] As discussed above, the device address 430 (FIG. 4) itself may be used in the address field 510 (FIG. 5) to identify devices 310, 320. However, unique device addresses may comprise many digits (e.g., ten, twenty, or even more). A large address field 510 may reduce the size that can be allotted to other fields (e.g., to instruction field 520). In addition, a signal 500 having a large address field 510 may require significant bandwidth for transmission over the CAN bus 330. High bandwidth signals 500 slow transmission speeds, and may need to be transmitted as multiple packets, increasing congestion on the CAN bus 330.

[0062] Accordingly, one embodiment of the building automation system may comprise dynamic addresses 420 (FIG. 4) for each device 310, 320 or category of device. That is, each device 310, 320 (or category of device) may be assigned a dynamic address 420 that is unique to a particular building automation system 300. The dynamic address 420 is preferably shorter than the device address 430 and still uniquely identifies the device 310, 320 (or category of device) in a particular building automation system 300 (or on a particular “leg” of the building automation system 300).

[0063] By way of example, consider three keypads Keypad A, Keypad B, and Keypad C. Keypad A and Keypad B are used in one building automation system (System A), and Keypad C is used in a separate building automation system (System B). Each keypad has a unique device address 430 that is different than any other device. For example, Keypad A may have device address “123ABC,” Keypad B may have device address “123XYZ,” and Keypad C may have device address “456ABC”. According to this embodiment, each keypad is assigned a dynamic address 420 when it is provided in the building automation system 300. For example, Keypad A is assigned dynamic address “10,” Keypad B is assigned dynamic address “20,” and Keypad C is assigned dynamic address “10.” Although Keypad A and Keypad C both have the same dynamic address (i.e., “10), these keypads are used in different building automation systems (System A and System B) and therefore are still uniquely identified in their respective systems. However, Keypad A and Keypad B are both used in System A, and therefore are assigned dynamic addresses that are unique to System A to avoid being misidentified.

[0064] Building automation system 300 may also comprise one or more maps 390 operatively associated with a bridge 380 (discussed in more detail below). Preferably, map 390 is stored in computer-readable storage accessible by the bridge 380. The map 390 may also be operatively associated with one or more of the distributed controllers 400.

[0065] Map 390 may be defined in any suitable manner. For example, map 390 may be defined as a text file using a word processor. Indeed, map 390 may be defined as part of instruction table 410. It is understood, however, that map 390 is not limited to any particular format.

[0066] In one embodiment, map 390 comprises the identity of each device 310, 320 on the CAN bus 330. Of course, a truncated version of the map 390 may also be used and include only some of the devices. For example, the truncated version of map 390 stored at a controlled device 320 may only identify control devices 310 from which the controlled device 320 will receive signals. As another example, truncated versions of the map 390 may be provided at bridges 380 where the building automation system 300 has more than one bridge 380. Each bridge 380 is provided with a truncated map 390 identifying only devices on the CAN bus 330 that are linked to a particular bridge 380.

[0067] The map 390 may be updated manually (e.g., by exporting, modifying, and importing the map 390). Alternatively, map 390 may be updated by automatically detecting or determining which of the devices 310, 320 are on the CAN bus 330. When a device 310, 320 is added to or removed from the CAN bus 330, bridge 380 and/or distributed controllers 400 automatically determine the status of the devices 310, 320 on the CAN bus (i.e., whether a device has been added or removed). Bridge 380 and/or distributed controllers 400 preferably update the maps 390 to reflect any changes.

[0068] By way of example, when a device 310, 320 is added to the CAN bus 330, distributed controller 400 operatively associated with the added device may issue a signal 500 comprising an address field 520 with its device address 430. When the bridge 380 and/or others of the distributed controllers 400 receive the signal 500 and do not recognize the device address 430 (e.g., it is not listed in map 390), map 390 may be updated with the identity of the added device. Similarly, when a device 310, 320 does not respond, map 390 may be updated to indicate that the non-responsive device has been removed from the CAN bus 330, or is otherwise offline.

[0069] If dynamic addressing is used, as discussed above, the bridge and/or distributed controllers 400 may also be used to assign a dynamic address to an added device. For example, bridge 380 and/or distributed controller 400 may assign a dynamic address that is not already being used, and update the map 390 accordingly. The bridge 380 preferably also issues a signal 500 comprising the dynamic address to the distributed controller 400 of the added device (e.g., as dynamic address 420). Similarly, the dynamic address 420 may be removed from map 390 when a device is removed from the CAN bus 330.

[0070] Also according to embodiments of building automation system, an acknowledgement may be issued over the CAN bus 330 when a signal 500 is received by the device. In one embodiment, the device sends an acknowledgement defined by the CAN protocol. Accordingly, if a signal is not acknowledged, the sending device may resend the signal.

[0071] According to an alternative embodiment, the distributed controller 400 of a receiving device may issue a targeted acknowledgement, by returning a signal 500 with an acknowledgement field 530 to the sending device. The acknowledgement field may comprise an acknowledgement or “ACK” message when a received signal is processed. Such an embodiment may be particularly desirable when more than one signal is delivered over the CAN bus 330 and must be assembled at the receiving device before it can be processed. Likewise, the acknowledgement field may be a negative acknowledged or “NAK” message when the received signal(s) cannot be read or are otherwise unusable. Optionally, an error message may also be generated for the user or service technician (e.g., by a suitable error-processing device on the CAN bus 330 and transmitted via external link 360).

[0072] As just mentioned, building automation system 300 may optionally comprise external link 360, as shown in FIG. 3. External link 360 may interface with the CAN bus 330 through one or more of the control devices 310, controlled devices 320, and/or bridge 380. Alternatively, external link 360 may interface via a port provided on the CAN bus 330. As discussed above for embodiment 100, external link 360 may be used to import/export instruction table(s) 410, maps 390, etc. External link 360 may also be used to troubleshoot the building automation system 300.

[0073] Building automation system 300 may also comprise an optional repeater 370, as shown in FIG. 3. Repeater 370 may be provided on the CAN bus 330 to extend the physical length of the CAN bus 330. As discussed above for embodiment 100, repeater 370 may be used to extend the physical length of the CAN bus 130, and/or increase the number of devices that can be provided on the CAN bus 130. For example, repeater 170 may amplify and/or clean (i.e., by improving the signal to noise ratio) signals issued over the CAN bus 130.

[0074] Building automation system 300 may also comprise one or more additional busses 331, which may be linked to one another via bridge 380 as shown in FIG. 3. Although not required, the optional bus 331 may also be a CAN bus. As discussed above, building automation system 300 may comprise separate and/or dedicated busses 330, 331 for different areas of the building and/or for different functions.

[0075] It is readily apparent that embodiments of the present invention represent an important development in the field of building automation. Having herein set forth preferred embodiments of the present invention, it is anticipated that suitable modifications can be made thereto which will nonetheless remain within the scope of the present invention.

Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7472203Jul 30, 2003Dec 30, 2008Colorado Vnet, LlcGlobal and local command circuits for network devices
US8219660 *Feb 26, 2010Jul 10, 2012Trane International Inc.Simultaneous connectivity and management across multiple building automation system networks
US8364319 *Mar 18, 2009Jan 29, 2013Inncom International Inc.Smart wall box
US8412789Aug 28, 2008Apr 2, 2013Robert Bosch GmbhSystem and method for connecting a security system using a network
US20100236824 *Mar 18, 2009Sep 23, 2010Inncom International Inc.Smart wall box
US20110213867 *Feb 26, 2010Sep 1, 2011Mccoy SeanSimultaneous connectivity and management across multiple building automation system networks
WO2004097589A2 *Apr 28, 2004Nov 11, 2004Colorado VnetBridge apparatus and methods of operation
WO2013059495A1 *Oct 18, 2012Apr 25, 2013Schneider Electric Buildings, LlcSelf-healing communications network
Classifications
U.S. Classification700/276
International ClassificationG05B15/02
Cooperative ClassificationG05B15/02
European ClassificationG05B15/02
Legal Events
DateCodeEventDescription
Oct 28, 2013ASAssignment
Effective date: 20130819
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AUTOMATED CONTROL TECHNOLOGY PARTNERS, INC.;REEL/FRAME:031515/0743
Owner name: GOOGLE INC., CALIFORNIA
May 21, 2013ASAssignment
Effective date: 20130515
Owner name: AUTOMATED CONTROL TECHNOLOGY PARTNERS, INC., FLORI
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:3VNET,INC.;REEL/FRAME:030460/0468
Mar 28, 2013ASAssignment
Owner name: 3VNET, INC., FLORIDA
Free format text: CHANGE OF NAME;ASSIGNOR:COLORADO VNET CORP;REEL/FRAME:030111/0296
Effective date: 20120503
Sep 3, 2010ASAssignment
Effective date: 20091015
Owner name: COLORADO VNET CORP., NEW HAMPSHIRE
Free format text: CHANGE OF NAME;ASSIGNOR:RUSSOUND ACQUISITION CORP.;REEL/FRAME:024933/0412
Aug 12, 2010ASAssignment
Effective date: 20100806
Owner name: RUSSOUND ACQUISITION CORP., NEW HAMPSHIRE
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:COLORADO VNET, LLC;REEL/FRAME:024823/0476
Apr 1, 2003ASAssignment
Owner name: COLORADO VNET, COLORADO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HESSE, SCOTT;NICOLAY, WILLIAM;ADAMSON, HUGH P.;REEL/FRAME:013908/0311
Effective date: 20030227