U.S. patent application number 11/216685 was filed with the patent office on 2005-12-29 for can bus router for building automation systems.
Invention is credited to Adamson, Hugh Patrick, Hesse, Scott, McDermid, John, Nicolay, William.
Application Number | 20050288823 11/216685 |
Document ID | / |
Family ID | 32926998 |
Filed Date | 2005-12-29 |
United States Patent
Application |
20050288823 |
Kind Code |
A1 |
Hesse, Scott ; et
al. |
December 29, 2005 |
Can bus router for building automation systems
Abstract
Systems and methods for implementing CAN bus routers in building
automation systems are disclosed. An exemplary system may comprise
a control area network (CAN) backbone. At least one CAN router may
be connected in-line to the CAN backbone. A plurality of automation
devices may be connected to the at least one CAN router for
communication over the CAN backbone.
Inventors: |
Hesse, Scott; (Longmont,
CO) ; Nicolay, William; (Loveland, CO) ;
Adamson, Hugh Patrick; (Boulder, CO) ; McDermid,
John; (Loveland, CO) |
Correspondence
Address: |
TRENNER LAW FIRM, LLC
12081 WEST ALAMEDA PARKWAY #163
LAKEWOOD
CO
80228
US
|
Family ID: |
32926998 |
Appl. No.: |
11/216685 |
Filed: |
August 31, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11216685 |
Aug 31, 2005 |
|
|
|
10382979 |
Mar 5, 2003 |
|
|
|
Current U.S.
Class: |
700/276 |
Current CPC
Class: |
G05B 15/02 20130101 |
Class at
Publication: |
700/276 |
International
Class: |
G05B 013/00 |
Claims
1. An expandable building automation system comprising: a control
area network (CAN) backbone; at least one CAN router connected
in-line to the CAN backbone; and a plurality of automation devices
connected to the at least one CAN router for communication over the
CAN backbone.
2. The building automation system of claim 1 wherein the at least
one CAN router is a hub.
3. The building automation system of claim 1 wherein the at least
one CAN router is a switch.
4. The building automation system of claim 1 wherein the at least
one CAN router receives a CAN signal over the CAN backbone and
automatically multicasts the CAN signal to at least one automation
device connected to the CAN router.
5. The building automation system of claim 1 further comprising a
plurality of CAN routers connected to one another in a daisy-chain
configuration.
6. The building automation system of claim 5 wherein the
daisy-chain configuration includes a first CAN router coupled
directly to the CAN backbone, and at least one expansion CAN router
coupled to the first CAN router.
7. The building automation system of claim 1 wherein at least one
of the automation devices includes a remote transmitter connected
to the CAN router.
8. The building automation system of claim 7 wherein at least one
of the automation devices includes control device issuing signals
to a controlled device via the remote transmitter.
9. The building automation system of claim 1 wherein the CAN
backbone remains operable even if the at least one automation
device is inoperable.
10. The building automation system of claim 1 further comprising at
least one CAN processor in the CAN router directly coupled to the
CAN backbone.
11. The building automation system of claim 10 further comprising
at least one cascading processor in the CAN router, the cascading
processor connected serially to the CAN processor.
12. The building automation system of claim 1 wherein the at least
one CAN router provides electrical power to automation devices
connected to the CAN router.
13. A method of configuring a building automation system,
comprising: providing a control area network (CAN) backbone for a
building having a plurality of automation zones; providing at least
one CAN router for connecting a plurality of automation devices in
each automation zone; and communicatively coupling the plurality of
automation devices to one another over the CAN backbone via the at
least one CAN router.
14. The method of claim 13 further comprising connecting at least
one CAN router to a primary CAN router in a daisy-chain
configuration.
15. The method of claim 13 further comprising connecting at least
one expansion CAN router to a primary CAN router in a daisy-chain
configuration.
16. The method of claim 13 further comprising connecting a
plurality of CAN routers to a primary CAN router.
17. The method of claim 13 further comprising communicatively
coupling a wireless automation device with the CAN backbone via the
at least one CAN router.
18. The method of claim 13 further comprising expanding capacity of
the CAN backbone without a repeater, while maintaining full
functionality of the CAN backbone.
19. A building automation system, comprising: localized
communication means for communicating control area network (CAN)
signals for building automation; and router means for connecting a
plurality of automation devices to the localized communication
means.
20. The building automation system of claim 19 wherein the router
means is expandable in a daisy-chain configuration.
21. The building automation system of claim 19 further comprising
means for maintaining integrity of the localized communication
means even if the router means is inoperable.
Description
PRIORITY CLAIM
[0001] This application claims priority as a continuation-in-part
of co-owned U.S. patent application Ser. No. 10/382,979 for
"BUILDING AUTOMATION SYSTEM AND METHOD" of Hesse, et al. (Attorney
Docket No. CVN.001.USP), filed Mar. 5, 2003, and corresponding
foreign priority application Ser. No. PCT/US/2004/005915 claiming
priority to Mar. 5, 2003 (Attorney Docket No. CVN.001.PCT), each
hereby incorporated herein for all that is disclosed.
TECHNICAL FIELD
[0002] The described subject matter relates to building automation,
and more particularly to Control Area Network (CAN) bus router for
building automation systems.
BACKGROUND
[0003] 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 examples.
[0004] 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.
[0005] 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).
[0006] Other building automation systems are available which
implement RS232 architecture to issue commands from the control
panel to the output devices. The RS232 architecture allows more
reliable data exchange between the control panel and the output
devices. However, the control panel (e.g., keypad) must be directly
connected to each of the output devices (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, making these
systems expensive to install and maintain. In addition, the RS232
architecture does not provide for error-handling.
SUMMARY
[0007] An exemplary embodiment of Control Area Network (CAN) bus
router may be implemented as a system. An expandable building
automation system may comprise a control area network (CAN)
backbone. At least one CAN router may be connected in-line to the
CAN backbone. A plurality of automation devices may be connected to
the at least one CAN router for communication over the CAN
backbone.
[0008] In another exemplary embodiment, CAN bus router may be
implemented as a method. An exemplary method of configuring a
building automation system, may comprise: providing a control area
network (CAN) backbone for a building having a plurality of
automation zones, providing at least one CAN router for connecting
a plurality of automation devices in each automation zone, and
communicatively coupling the plurality of automation devices to one
another over the CAN backbone via the at least one CAN router.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1 is a high-level schematic diagram of an exemplary
building ion system.
[0010] FIG. 2 is an exemplary instruction table for use with in a
building automation system.
[0011] FIG. 3 is a high-level schematic diagram of another
exemplary building automation system.
[0012] FIG. 4 is a high-level schematic diagram of exemplary
distributed controllers for a building automation system.
[0013] FIG. 5 illustrates an exemplary signal which may be issued
over a CAN bus in a building automation system.
[0014] FIG. 6 is a high-level schematic diagram of yet another
exemplary building automation system, illustrating the use of CAN
routers.
[0015] FIG. 7 is a high-level schematic diagram of an exemplary CAN
router for use with a building automation system.
[0016] FIG. 8 is an illustration of exemplary CAN routers
implemented in an exemplary daisy-chain configuration.
[0017] FIG. 9 is a high-level schematic diagram of another
exemplary CAN router for use with a building automation system.
DETAILED DESCRIPTION
[0018] Briefly, building automation systems 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 examples.
[0019] An exemplary building automation system 100 may include one
or more automation devices, such as, control devices (e.g., a
keypad) operatively associated with one or more controlled devices
(e.g., a triac board). Control devices issue commands, which in
turn instruct the controlled devices to perform a function. By way
of example, when a homeowner (or more generally, a user) presses a
key on the keypad, 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.
[0020] It should be understood that the foregoing example is
provided in order to better understand an exemplary environment in
which building automation systems may be implemented. Of course
building automation systems may also be implemented with any of a
wide range of other types and configurations of automation devices,
and for various functions beyond lighting a room, which are now
known or that may be developed in the future. The particular types
and configurations of automation devices may depend in part on
design considerations, which can be readily defined and implemented
by one having ordinary skill in the art after becoming familiar
with the teachings herein.
[0021] In an exemplary embodiment, the automation devices are
operatively associated with a control area network (CAN) bus. The
CAN bus may comprise a two-wire differential serial data bus. The
CAN bus is capable of high-speed data transmission (about 1
Megabits per second (Mbits/s)) over a distance of about 40 meters
(m), and may be extended, e.g., 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 integrity of the data.
[0022] It is noted that the CAN bus implemented for building
automation 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 CAN bus may
also include error handling and bus arbitration, enhancing
performance of the building automation system. 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).
[0023] In addition, more than one CAN bus may be combined to extend
the functionality of the building automation system. 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 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.
[0024] FIG. 1 is a high-level schematic diagram of an exemplary
building automation system 100. Exemplary building automation
system 100 may comprise a CAN bus 130 for a number of automation
devices. For example, one or more control devices 110-113 (also
generally referred to herein as control device 110 or control
devices 110) may be operatively associated with the CAN bus 130. In
addition, one or more controlled devices 120-124 (also generally
referred to herein as controlled device 120 or controlled devices
120) may be operatively associated with the CAN bus 130.
[0025] It is noted that suitable interfaces (not shown) may be
provided for coupling the control device 110 and controlled device
120 to the CAN bus 130 for issuing and receiving CAN signals over
the CAN bus 130. Such interfaces are readily understood by those
having ordinary skill in the art, and may be readily provided for
use with the building automation systems described herein after
having become familiar with the teachings herein.
[0026] An exemplary CAN bus 130 may be implemented as 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 it is noted, however, that CAN bus 130
is not limited to any particular version. It is intended that other
specifications for the CAN bus, now known or later developed, may
also be implemented for the building automation systems described
herein.
[0027] Before continuing, it is noted that the term "control
device" as used herein is defined to include 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 passes 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.
[0028] Control device 110 may be any suitable device and is not
limited to a keypad or keyboard. Examples of other types of control
devices include, but are not limited to, graphical user interfaces
(GUI), personal computers (PC), remote control devices, security
sensors, temperature sensors, light sensors, and timers.
[0029] It is also noted that the term "controlled device" as used
herein is defined to include any suitable device which is generally
configured to perform one or more functions in response to a signal
issued by a control device. In an exemplary embodiment, 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.
[0030] By way of example, a controlled device may be implemented as
a controllable alternating current (AC) switch and associated
processing hardware and/or software, collectively referred to as a
"triac board." When the triac board receives an instruction to dim
the main lighting from a control device (e.g., a keypad), the triac
board causes the main lighting to dim (e.g., to 50% intensity).
[0031] It is further noted that the terminology "control device"
and "controlled device" is not limited to automation devices
dedicated to "control" or "controlled" functionality, although such
dedicated devices may also be implemented. In exemplary
embodiments, automation devices may also be implemented as
"multi-function" automation devices to perform the functions of
both a control device and a controlled device. Although a
multi-function automation device is not shown separately in FIG. 1,
multi-function automation devices are represented in FIG. 1 as
control device 110 and controlled device 120. That is, when the
multi-function automation device performs the functions of a
control device, it is represented in FIG. 1 as control device 110.
When the multi-function automation device performs the functions of
a controlled device, it is represented in FIG. 1 as controlled
device 120.
[0032] Continuing now with the description of exemplary building
automation system 100, 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 (e.g.,
wireless) 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. Alternatively, control device 110 and/or
controlled device 120 may be removably linked to the CAN bus 130 by
a suitable "plug-type" connection (also referred to as a "bus
tap"). Control device 110 and/or controlled device 120 may also be
remotely (or wirelessly) linked to the CAN bus 130, for example via
an RF link.
[0033] Building automation system 100 may also comprise a central
controller 140 operatively associated with the CAN bus 130. Central
controller 140 may also be linked to the CAN bus 130 in any
suitable manner, such as described above for control device 110 and
controlled device 120.
[0034] 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 an
exemplary 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.
[0035] 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.
[0036] 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 teachings herein.
[0037] In an exemplary embodiment, 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.
[0038] 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 150, as described in more
detail below with reference to FIG. 2.
[0039] Optionally, building automation system 100 may comprise one
or more external link(s) 160. In an exemplary 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). In an exemplary embodiment, external link 160 may be used to
import/export the instruction table 200 (e.g., at installation or
for changes).
[0040] 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.).
[0041] 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 provided via a local area network (LAN), a wide area
network (WAN), an Intranet, or a telephony link, to name only a few
examples. 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.
[0042] Building automation system 100 may also comprise one or more
optional repeater(s) 170, e.g., 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.
[0043] Building automation system 100 may also comprise one or more
additional busses 131. In an exemplary embodiment, the optional bus
131 is also a CAN bus. In an exemplary 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 does not affect operation
of the other CAN bus 131.
[0044] FIG. 2 is an illustration of an exemplary instruction table
200 for use in a building automation system. Instruction table 200
may be defined based on various parameters, such as the needs and
desires of the building occupant. The instruction table 200 may be
operatively associated with a central controller for use with a
building automation system (e.g., the central controller 140 and
building automation system 4100 in FIG. 1). For example, the
instruction table 200 may be stored on suitable computer readable
storage media accessible by the central controller.
[0045] Exemplary instruction table 200 may comprise signal data 205
and instructions 210. Signal data 205 corresponds to the input
which may be received by a central controller (e.g., the central
controller 140 in FIG. 1). In an exemplary embodiment, signal data
205 comprises the identity of the control device (Device ID) and
the type of input received at the control device (Input ID). The
instructions 210 identify functions that a controlled device (e.g.,
controlled device 120 in FIG. 1) may perform when the controlled
device receives the corresponding signal data 205.
[0046] By way of example, signal data 205 may comprise Device
ID=Device 1 and Input ID=Key 1. The instructions corresponding to
this signal data 205 may be "Main Lighting 50%" and "Perimeter
Lighting ON". In this example, if Device 1 issues a signal
indicating that Key 1 is actuated, the central controller adjusts
the "Main Lighting" to 50% intensity, and turns on the perimeter
lighting by issuing instructions to the appropriate controlled
device(s).
[0047] It is noted that the instruction table 200 may be defined in
any suitable manner. For example, instruction table 200 may be
defined as a code-driven table. However, instruction table 200 is
not limited to any particular format and the embodiment shown in
FIG. 2 is provided only for purposes of illustration.
[0048] In an exemplary embodiment, instruction table 200 may be
generic (i.e., applicable to one or more predefined configurations
of the building automation system 100). However, in another
exemplary embodiment, the instruction table 200 may be custom or
tailored to each building automation system 100. A custom
instruction table may be defined after the configuration of a
particular building automation system 100 is known.
[0049] According to either embodiment, instruction table 200 may be
modified, reconfigured, or replaced, based at least in part on the
changing needs and/or desires of the building occupants. For
example, when the building changes occupancy, the instruction table
200 may be changed to reflect needs and/or desires of the new
occupants. Modifying, reconfiguring, or replacing the instruction
table 200 is particularly advantageous when one or more automation
devices are added or removed from the building automation system.
Modifying or replacing the instruction table 200 may also be used
to change one or more parameters for the automation devices, such
as, e.g., defining a new key on a keypad, changing the lighting
intensity for a triac board, etc.
[0050] With reference now to FIGS. 1 and 2, exemplary building
automation system 100 may be operated as follows. 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 200 is provided
for use by the controller 140. Instruction table 200 may also be
defined for the building automation system 100.
[0051] After 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.
[0052] In an exemplary 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. 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).
[0053] Although addressing may be used, in other embodiments the
device may respond even without an address if the signal identifies
the device function(s). For example, a light controller may respond
to a signal related to lighting and "ignore" signals related to
environmental controls (e.g., heating/humidity/air
conditioning).
[0054] In an exemplary 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.
[0055] The central controller 140 receives the signal from control
device 110. Central controller 140 responds by accessing the
instruction table 200 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 200 in FIG. 2 are "Main Lighting
50%" and "Perimeter Lighting ON". The central controller 140 issues
these instructions over the CAN bus 130.
[0056] In an exemplary 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.
[0057] 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 automation 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.
[0058] Of course it is understood that the above examples are
merely illustrative of exemplary central control systems and
methods, and is not intended to be limiting. Indeed, the building
automation system 100 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 herein.
[0059] Exemplary Distributed Control Systems and Methods
[0060] FIG. 3 is a high-level schematic diagram of another
exemplary building automation system 300. Exemplary building
automation system 300 may include 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 and described above.
[0061] Exemplary building automation system 300 may comprise
distributed controller(s) (such as distributed controller 400 shown
in FIG. 4) operatively associated with one or more of the
automation devices. For example, distributed controller(s) may be
provided for each control device 310, for each controlled device
320, or for both control devices 310 and controlled devices
320.
[0062] Building automation system 300 may also comprise one or more
maps 390 operatively associated with a bridge 380 (discussed in
more detail below). In an exemplary embodiment, 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.
[0063] 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 an instruction table. It
is understood, however, that map 390 is not limited to any
particular format.
[0064] In an exemplary 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.
[0065] 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/210 on the CAN bus (i.e., whether a device has been
added or removed). Bridge 380 and/or distributed controllers 400
may update the maps 390 to reflect any changes.
[0066] By way of example, when a device 310, 320 is added to the
CAN bus 330, a distributed controller operatively associated with
the added device may issue a signal with its device address. When
the bridge 380 and/or others of the distributed controllers receive
the signal and do not recognize the device address (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.
[0067] If dynamic addressing is used, as discussed above, the
bridge and/or distributed controllers may also be used to assign a
dynamic address to an added device. For example, bridge 380 and/or
distributed controller may assign a dynamic address that is not
already being used, and update the map 390 accordingly. The bridge
380 may also issue a signal comprising the dynamic address to the
distributed controller of the added device (e.g., as a dynamic
address). Similarly, the dynamic address may be removed from map
390 when a device is removed from the CAN bus 330.
[0068] Building automation system 300 may also optionally comprise
an external link 360. 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 with reference to FIG. 1, external link 360 may be used to
import/export instruction table(s), maps 390, etc. External link
360 may also be used to troubleshoot the building automation system
300.
[0069] Building automation system 300 may also comprise an optional
repeater 370. Repeater 370 may be provided on the CAN bus 330 to
extend the physical length of the CAN bus 330. As discussed above
with reference to FIG. 1, repeater 370 may be used to extend the
physical length of the CAN bus, and/or increase the number of
devices that can be provided on the CAN bus. For example, the
repeater may amplify and/or clean signals (i.e., by improving the
signal to noise ratio) issued over the CAN bus.
[0070] 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.
[0071] FIG. 4 is a high-level schematic diagram of exemplary
distributed controllers for a building automation system.
Distributed controller 400 may be any suitable device configured to
process signals (such as the signal 500 shown in FIG. 5). In an
exemplary 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.
[0072] Exemplary distributed controllers 400 may comprise one or
more microprocessors, PLAs (e.g., FPGA, ASIC), etc. It is noted
that distributed controllers 400 may be operatively associated with
automation devices, such as, control device 310 and/or controlled
device 320, in any suitable manner. In an exemplary embodiment,
distributed controllers 400 are provided at, and are directly
linked to the automation device (e.g., as part of the same computer
board).
[0073] In an exemplary embodiment, only the device operatively
associated with a failed or otherwise offline distributed
controller 400 is affected by such failure (or by being offline).
Other automation devices of the building automation system 300 may
continue in operation even though one or more of the distributed
controllers 400 is no longer operational.
[0074] In operation, distributed controller 400 may generate
signals. For example, distributed controller 400 may generate a
signal comprising an instruction. That is, when control device 310
receives input, distributed controller 400 may use instruction
table 410 to generate a signal comprising corresponding
instruction(s) for controlled device. Likewise, distributed
controller 400 may perform any number of functions for the
controlled device. In an exemplary embodiment, distributed
controller 400 generates instructions for controlled device based
on signals that are received over the CAN bus.
[0075] In an exemplary embodiment, the automation devices may each
comprise a device address 430. Each device address 430 may be
unique to the device. For example, device addresses 430 may be
assigned to the automation devices 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 automation device in a
suitable memory, although other embodiments are also contemplated
as being within the scope of the teachings herein. In any event, no
other automation device has the same device address 430, thereby
reducing the likelihood that the automation device is
misidentified. For example, a triac board is not misidentified on
the CAN bus as a security board (e.g., activating an alarm when the
user intends to turn on the lights).
[0076] It is understood that other embodiments are also
contemplated. In another exemplary 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 and will become
apparent to those skilled in the art after having become familiar
with the teachings herein.
[0077] FIG. 5 illustrates an exemplary signal which may be issued
over a CAN bus in a building automation system. Exemplary signal
500 may include an address of the device(s), for example, in an
address field 510. Accordingly, the signals 500 may be addressed to
specific automation devices, supporting so called "peer-to-peer"
communication over the CAN bus even though the signal 500 is
broadcast to each of the devices on the CAN bus. Addressing also
enables particular automation device(s) on the CAN bus to be reset
without having to reset all of the devices on the CAN bus (i.e.,
only the device(s) identified in the address field 510 perform a
reset instruction in field 520).
[0078] Although the device address 430 itself may be provided in
the address field 510 of the signal 500 to identify automation
devices, unique device addresses may be too long to effectively
implement, e.g., including ten, twenty, or even more digits. That
is, 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.
[0079] In an exemplary embodiment, dynamic addressing may be
implemented (e.g., dynamic address 420 in FIG. 4) for each
automation device or category of devices. That is, each automation
(or category of devices) may be assigned a dynamic address 420 that
is unique to a particular building automation system. The dynamic
address 420 may be shorter than the device address 430 and still
uniquely identifies the automation device (or category of devices)
in a particular building automation system (or on a particular
"leg" of the building automation system).
[0080] 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 (e.g., device address 430 in FIG. 4) 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 (e.g.,
dynamic address 420 in FIG. 4) when it is provided in the building
automation system. 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.
[0081] With reference now to FIGS. 3-5, exemplary building
automation system 300 may be operated as follows. 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.
[0082] 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. In an exemplary embodiment, 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.
[0083] Signals may also 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).
[0084] Also in exemplary embodiments, an acknowledgement may be
issued over the CAN bus 330 when a signal 500 is received by the
device. For example, the device may send an acknowledgement defined
by the CAN protocol. Accordingly, if a signal is not acknowledged,
the sending device may resend the signal.
[0085] In alternative exemplary 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).
[0086] Exemplary CAN Routers
[0087] FIG. 6 is a high-level schematic diagram of yet another
exemplary building automation system 600, illustrating the use of
CAN routers. As discussed above with reference to FIGS. 1 and 3,
building automation system 600 may comprise one or more automation
devices 610a-g, such as control devices (e.g., keypads) and/or
controlled devices (e.g., motors). The automation devices may also
include one or more remote transmitters 610f for remotely (or
wirelessly) communicating with one or more remote receivers 615.
The automation devices 610a-g (also referred to as automation
device 610 and automation devices 610) are operatively associated
with one another over a network or a plurality of networks, e.g.,
via CAN routers 670-672 (discussed in more detail below).
[0088] The building automation system 600 may include at least one
CAN bus backbone. Implementing a CAN bus backbone provides
localized wiring, easing installation and troubleshooting. In an
exemplary embodiment, the CAN bus backbone is configured as subnets
620 and 625. One or more bridges 630a-b and 635a-b (e.g., a primary
bridge and a secondary or "shadow" bridge) may link the subnets 620
and 625 to one another via a local area network 640 (e.g., an
Ethernet LAN).
[0089] CAN bus subnets and redundant bridges are described in more
detail in co-owned U.S. patent application Ser. No. 10/807,930
entitled "Bridge Apparatus and Methods of Operation" of Ogawa, et
al., hereby incorporated herein for all that is disclosed. Briefly,
the subnet configuration may provide fault protection for the
building automation system 600 by rerouting signals around a
disconnection in the subnet (e.g., as illustrated at 650). In
addition, each bridge in a subnet may be provided with a copy of
the operating information for the respective subnet, so that
operation of the subnet may be automatically switched in the event
one of the bridges fails. For example, operation of the subnet 620
may be switched from the primary bridge 630a to the secondary
bridge 630b if the primary bridge fails.
[0090] The automation devices 610 may be communicatively coupled to
the CAN bus 660, 665 (e.g., in the subnet 620 or 625, respectively)
by one or more CAN router(s) 670-672. CAN routers provide a single
connection point on the CAN bus for a plurality of automation
devices, providing a localized wiring system, making it easier to
install the automation devices. If one or more automation device
fails, the other automation devices continue to operate. The
failure of automation devices do not affect operation of other
devices or the CAN backbone, and may be readily replaced without
having to turn off power or otherwise shut down the building
automation system.
[0091] Building automation systems employing CAN routers are also
flexible, and may be readily expanded even after initial
installation. In addition, troubleshooting is easier and can be
done with less sophisticated diagnostic tools.
[0092] In an exemplary embodiment, one or more of the CAN routers
670-672 may be implemented as a hub. The term "hub" as used herein
to mean a network connection device which communicatively couples
devices on the CAN bus, e.g., in a "star" configuration. It is
noted that the hub may be a passive hub (e.g., for connecting
without adding to the data bits passing through), or an active hub
(e.g., for regenerating the data bits to maintain signal strength).
The hub may also be implemented as an "intelligent" hub, which
includes a processor and basic operating system for handling server
or network control operations. In an exemplary embodiment, the hub
may also interconnect different types of networks, thereby
performing a bridging function. When functioning as a hub, the
router sends all of the packets received on each of the ports, out
through all of the other ports, without interpretation.
[0093] In another exemplary embodiment, one or more of the CAN
routers 670-672 may be implemented as a switch. The term "switch"
is used herein to mean a network connection device which
cross-connects CAN bus segments, while providing each
sender-receiver pair the full bandwidth of the network. That is,
each port on the switch may provide full bandwidth to a single
station, or connect to another switch or hub with several stations.
The switch may also be implemented as an intelligent switch, e.g.,
having a processor and basic operating system for handling server
or network control operations.
[0094] When functioning as a switch, the router keeps track of all
addresses of the connected devices and only sends the packets to a
device which are needed by that device. In addition, any packets
destined for another device plugged into the same board (and not
required by any other device in the system) may be sent only to the
addressed device.
[0095] In another exemplary embodiment, one or more of the CAN
routers 670-672 may be implemented as a strict router. When acting
as a strict router, the router checks the address fields of each
packet and determines which subnet it belongs to. The router only
retransmits it to ports configured to handle the appropriate subnet
traffic.
[0096] In another exemplary embodiment, one or more of the CAN
routers 670-672 may be implemented as a gateway. When acting as a
gateway, the router checks each packet to see if it is required to
be sent on any of the other non-CAN ports (such as Ethernet or
RS232). The packet may be encapsulated for the other interface. The
router also monitors traffic from the other router(s) and sends
packets out the CAN ports.
[0097] It is noted that in exemplary embodiments, the router may be
configured to set one or more of the ports to any combination of
the above functions (e.g., hub, switch, gateway, etc.).
[0098] In addition, one or more of the CAN routers 670-672 may be
programmed to automatically reconfigure the baud rate. This means
that when a new CAN device is plugged into the router, the router
determines what the data rate the new CAN device is operating at,
and match the data rate of the router to the CAN device. The router
may also be set to automatically alter the data rate to achieve the
maximum reliable data rate possible.
[0099] Although CAN routers are described above with reference to
building automation system 600, it is noted that CAN routers are
not limited to use with any particular type or configuration of
building automation system. For example, CAN routers may also be
implemented in the building automation system 100 described above
with reference to FIG. 1, the building automation system 300
described above with reference to FIG. 3, and with any other
building automation system implementing a CAN bus.
[0100] FIG. 7 is a high-level schematic diagram of an exemplary CAN
router 700 for use with a building automation system (e.g.,
building automation system 100, 300, or 600, discussed above).
Exemplary CAN router 700 may be connected in-line to the CAN bus
backbone. A plurality of automation devices may be connected to the
CAN router 700 for communications with other automation devices
connected directly to the CAN router 700 and/or with other
automation devices on the CAN bus backbone (e.g., connected to
other CAN routers) or in other CAN subnets or other networks (e.g.,
devices on LAN 640 in FIG. 6).
[0101] Exemplary router 700 may include a housing 710, with a
plurality of input/output (I/O) ports, such as, e.g., power-in 720,
power-out 721, CAN-in 722, CAN-out 723. Any of a wide variety of
other types of I/O ports may also be provided (e.g., illustrated as
in FIG. 7 "Port n" 725). For example, other types of I/O ports may
include a connection for remote (or wireless) control (e.g., an IR
or RF receiver), troubleshooting port(s), and status signaling
port(s), to name only a few examples.
[0102] Exemplary router 700 may also include a plurality of
processors 730-734, each linked to the CAN bus backbone (e.g.,
between the CAN-in port 722 and CAN-out port 723). In an exemplary
embodiment, processors 730-734 may be implemented using an SJA2020
processor commercially available from Philips Electronics. The
SJA2020 processor has 6 built-in CAN controllers. Other processors
that do not include built-in CAN controllers may also be
implemented by communicating with any number of external
controllers (thereby reducing the number of microcontrollers on the
board). Still other types of processors may also be implemented,
and are not limited to the SJA 2020 processor.
[0103] The processors 730-734 serve several different functions.
For example, one processor may be selected to act as the main
controller, i.e., for communicating with the bridge (if present).
These communications may include notifying the bridge of any alarm
conditions on the router (e.g., low voltage). The main controller
is also responsible for receiving new firmware from the bridge, and
then sending it to each of the slave processors. The main
controller also monitors the status of the other processors.
[0104] Processors 730-734 may also provide an interface with the
CAN backbone and one or more automation devices connected to the
processors at device ports 740a-e, 741a-e, etc. The processors may
monitor each of the CAN ports, and when it detects that a cable has
been plugged in, the processor begins accepting packets and
determining how to handle the packets.
[0105] In an exemplary embodiment, processors 730-734 may be linked
to a plurality of device ports 740a-e, 741a-e, etc. Although any
suitable device ports 740a-e, 741a-e, etc. may be implemented, in
an exemplary embodiment, the device ports may include standard
connections, such as, e.g., RJ-45 ports to ease installation,
device replacement, and reconfiguration. In addition, any number of
device ports may be provided for each processor, limited only by
the number of devices a processor can effectively manage (e.g.,
typically based on the CAN bus definition).
[0106] Electrical power may be readily connected to the CAN router
700, e.g., at port 720, and provided to the processors 730-734. For
example, an electrical power source may include local electrical
wiring. Optionally, electrical power may be provided via a separate
wire in the same cable used to route the CAN bus. Electrical power
may also be continued to other devices (e.g., other CAN routers)
via port 721.
[0107] Electrical power may also be provided to each of the
automation devices from the CAN router 700, e.g., via device ports
740. Alternatively, electrical power may be provided directly to
the automation device (e.g., using electrical wiring local to the
automation devices).
[0108] FIG. 8 is an illustration of exemplary CAN routers 800-802
implemented in an exemplary daisy-chain configuration. Exemplary
CAN routers 800-802 are shown including processors (referenced
generally as 810) and device ports (referenced generally as 820),
as described above for the exemplary CAN router 700 shown in FIG.
7. The CAN routers 800-802 may be connected to one another to
expand device capacity without having to extend the CAN
backbone.
[0109] The term "daisy-chain" as it is used herein to refer to the
configuration of CAN routers 800-802 means connecting a primary CAN
router to the CAN backbone, and then connecting other CAN routers
to the device ports. By way of example, primary CAN router 800 is
shown in FIG. 8 connected in-line to the CAN backbone, e.g., at 830
and 835. Primary CAN router 800 is also connected in-line to
electrical power, e.g., at 840 and 845. CAN router 801 is connected
to CAN router 800 at one of the device ports 821, and CAN router
802 is connected in turn to CAN router 801 at one of the device
ports 822.
[0110] The CAN routers 801 and 802 are shown in FIG. 8 as expansion
routers. Expansion routers may be compact, e.g., including fewer
processors and device ports. In addition, a daisy-chain port may be
provided to connect with the CAN router on the CAN backbone,
instead of providing CAN-in and CAN-out ports for in-line
configuration on the CAN backbone. However, it is noted that
expansion routers 801 and 802 do not need to be implemented for a
daisy-chain configuration. In other embodiments, a plurality of CAN
routers (e.g., CAN routers 700 in FIG. 7) may be implemented in a
daisy-chain configuration, e.g., by connecting the CAN-in port of
one CAN router to a device port of another CAN router.
[0111] It is noted that more than one daisy-chain configuration may
be implemented in the building automation system. For example, CAN
router 800 may include a plurality of daisy-chains by connecting
additional CAN routers (e.g., CAN router 805) to different device
ports (e.g., device port 823) in the CAN router 800.
[0112] It is also noted that electrical power may be provided to
the CAN routers 801-802 via device port 821. Alternatively,
electrically power may be provided to the CAN routers 801-802 from
other power sources, e.g., via electrical wiring local to the CAN
routers 801-802.
[0113] Furthermore, it is noted that daisy-chained CAN routers do
not need to be connected to device ports, and may instead be
connected to dedicated ports (not shown) in the CAN router 800
provided for making daisy-chain connections.
[0114] The daisy-chain configuration may be implemented to extend
functionality of the CAN backbone beyond the definition of the CAN
bus protocol. That is, the CAN bus protocol may only allow X number
of devices (e.g., currently 256 devices, depending on the hardware)
on the CAN bus. However, by implementing the CAN routers in a
daisy-chain configuration, the processors are linked serially to
one another and not directly to the CAN bus. Accordingly, there is
no limit to the number of automation devices that may be
implemented on the CAN system without the need for repeaters. In
other embodiments, repeaters may also be implemented on the CAN
backbone, along with the daisy-chain configuration, to further
extend functionality of the CAN backbone.
[0115] FIG. 9 is a high-level schematic diagram of another
exemplary CAN router 900 for use with a building automation system.
It is noted that the I/O ports have already been described with
reference to FIG. 7, and therefore are not repeated here.
[0116] In this embodiment, CAN router 900 includes cascading
processors. Cascading processors may also be implemented to extend
functionality of the CAN backbone beyond the definition of the CAN
bus protocol, e.g., without having to implement a repeater on the
CAN backbone. In addition, cascading processors may be implemented
in a daisy-chain configuration (e.g., as discussed above with
reference to FIG. 8) to further extend functionality of the CAN
backbone.
[0117] The term "cascading processors" is used herein to mean at
least a first processor in the CAN router is connected to the CAN
backbone, and one or more additional processors are connected
serially to the first processor. In FIG. 9, for example, CAN router
900 includes a CAN processor 910 connected to the CAN backbone,
e.g., at connection 915. CAN router 900 also includes cascading
processors 920-923, serially linked to the CAN processor 910. The
processors (CAN processor 910 and/or cascading processors 920-923)
also include a number of device ports (generally referred to as
device ports 930) for connecting automation devices.
[0118] In addition to the specific embodiments explicitly set forth
herein, other aspects and embodiments will be apparent to those
skilled in the art from consideration of the specification
disclosed herein. It is intended that the specification and
illustrated embodiments be considered as examples only.
* * * * *