US20050288823A1 - Can bus router for building automation systems - Google Patents
Can bus router for building automation systems Download PDFInfo
- Publication number
- US20050288823A1 US20050288823A1 US11/216,685 US21668505A US2005288823A1 US 20050288823 A1 US20050288823 A1 US 20050288823A1 US 21668505 A US21668505 A US 21668505A US 2005288823 A1 US2005288823 A1 US 2005288823A1
- Authority
- US
- United States
- Prior art keywords
- router
- building automation
- automation system
- devices
- bus
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims abstract description 15
- 238000004891 communication Methods 0.000 claims abstract description 11
- 230000008878 coupling Effects 0.000 claims description 4
- 238000010168 coupling process Methods 0.000 claims description 4
- 238000005859 coupling reaction Methods 0.000 claims description 4
- 230000006870 function Effects 0.000 description 22
- 238000010586 diagram Methods 0.000 description 12
- 238000009429 electrical wiring Methods 0.000 description 6
- 238000009434 installation Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 238000004378 air conditioning Methods 0.000 description 3
- 238000010438 heat treatment Methods 0.000 description 3
- 238000003860 storage Methods 0.000 description 3
- 238000013024 troubleshooting Methods 0.000 description 3
- 230000008676 import Effects 0.000 description 2
- 229920000747 poly(lactic acid) Polymers 0.000 description 2
- 238000003825 pressing Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 230000003213 activating effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000001172 regenerating effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B15/00—Systems controlled by a computer
- G05B15/02—Systems controlled by a computer electric
Definitions
- the described subject matter relates to building automation, and more particularly to Control Area Network (CAN) bus router for building automation systems.
- CAN Control Area Network
- Building automation 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.
- 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.
- the commands may be distorted or lost due to “noise” in the electrical wiring.
- such systems are limited to relatively few output devices.
- RF radio frequency
- RF transmission is typically limited in range (e.g., by government regulation) and is subject to interference (e.g., from other RF devices).
- RS232 architecture allows more reliable data exchange between the control panel and the output devices.
- the control panel e.g., keypad
- the output devices i.e., a point-to-point or so-called “hub-and-spoke” arrangement.
- hub-and-spoke Such an arrangement can only be used for short runs and is wiring intensive, making these systems expensive to install and maintain.
- the RS232 architecture does not provide for error-handling.
- 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.
- 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.
- CAN control area network
- FIG. 1 is a high-level schematic diagram of an exemplary building ion system.
- FIG. 2 is an exemplary instruction table for use with in a building automation system.
- FIG. 3 is a high-level schematic diagram of another exemplary building automation system.
- FIG. 4 is a high-level schematic diagram of exemplary distributed controllers for a building automation system.
- FIG. 5 illustrates an exemplary signal which may be issued over a CAN bus in a building automation system.
- FIG. 6 is a high-level schematic diagram of yet another exemplary building automation system, illustrating the use of CAN routers.
- FIG. 7 is a high-level schematic diagram of an exemplary CAN router for use with a building automation system.
- FIG. 8 is an illustration of exemplary CAN routers implemented in an exemplary daisy-chain configuration.
- FIG. 9 is a high-level schematic diagram of another exemplary CAN router for use with a building automation system.
- 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.
- 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.
- a homeowner or more generally, a user
- 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.
- 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.
- 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.
- 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).
- CAN bus may be combined to extend the functionality of the building automation system.
- 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.
- 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.
- one or more control devices 110 - 113 also generally referred to herein as control device 110 or control devices 110
- one or more controlled devices 120 - 124 also generally referred to herein as controlled device 120 or controlled devices 120
- controlled device 120 or controlled devices 120 may be operatively associated with the CAN bus 130 .
- suitable interfaces 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.
- 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).
- ISO International Standards Organization
- 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.
- 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.
- control device 110 may be a keypad or keyboard.
- a key or sequence of keys
- 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.
- 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.
- GUI graphical user interfaces
- PC personal computers
- remote control devices security sensors, temperature sensors, light sensors, and timers.
- 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.
- the controlled device 120 receives the instruction over the CAN bus 130 , as will be described in more detail below.
- controlled device 120 may also receive input from sources other than the CAN bus 130 .
- 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.”
- AC alternating current
- 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).
- 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.
- automation devices may also be implemented as “multi-function” automation devices to perform the functions of both a control device and a controlled device.
- 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 .
- 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.
- control device 110 and/or controlled device 120 may be permanently linked to the CAN bus 130 by a hard-wire connection.
- 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.
- 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 .
- 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 .
- 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 .
- 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.
- PDA programmable logic devices
- FPGA field programmable gate array
- ASIC application-specific integrated circuit
- 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 .
- 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.
- ancillary devices for example, power supplies, electronic controls, input/output (I/O) devices, computer readable storage media, etc.
- I/O input/output
- 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.
- 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 .
- 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 .
- building automation system 100 may comprise one or more external link(s) 160 .
- external link 160 may comprise a link from central controller 140 to another network such as the Internet via an Internet service provider (ISP).
- ISP Internet service provider
- external link 160 may be used to import/export the instruction table 200 (e.g., at installation or for changes).
- External link 160 may also be used to troubleshoot the building automation system 100 .
- 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.).
- the external link 160 is not limited to an ISP link.
- 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.
- 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.
- external link 160 may comprise a temporary connection for use by a service technician.
- the external link 160 may comprise a link suitable for connecting a laptop computer to the building automation system 100 .
- 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 .
- repeater 170 may amplify signals and/or “clean” (e.g., improve the signal to noise ratio) the signals issued over CAN bus 130 .
- Building automation system 100 may also comprise one or more additional busses 131 .
- the optional bus 131 is also a CAN bus.
- 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.
- 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 .
- 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 ).
- the instruction table 200 may be stored on suitable computer readable storage media accessible by the central controller.
- 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 ).
- 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 .
- the instructions corresponding to this signal data 205 may be “Main Lighting 50%” and “Perimeter Lighting ON”.
- 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).
- instruction table 200 may be defined in any suitable manner.
- instruction table 200 may be defined as a code-driven table.
- instruction table 200 is not limited to any particular format and the embodiment shown in FIG. 2 is provided only for purposes of illustration.
- 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.
- 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.
- 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 .
- 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.
- control device 110 may issue signal(s) that are representative of the input (e.g., the keys that were pressed).
- signal(s) that are representative of the input (e.g., the keys that were pressed).
- 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 .
- 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).
- the device may respond even without an address if the signal identifies the device function(s).
- a light controller may respond to a signal related to lighting and “ignore” signals related to environmental controls (e.g., heating/humidity/air conditioning).
- 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.
- 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 .
- 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.
- one of the devices may be a triac board for the main lighting circuit
- another of the automation devices e.g., controlled device 123 in FIG. 1
- a single-pull single-throw switching board e.g., a switch with associated processing hardware and software
- controlled device 122 responds to the instruction “Main Lighting 50%” by dimming the main lighting circuit to 50%
- 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.
- 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.
- 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.
- 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 .
- Building automation system 300 may also comprise one or more maps 390 operatively associated with a bridge 380 (discussed in more detail below).
- 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.
- Map 390 may be defined in any suitable manner.
- map 390 may be defined as a text file using a word processor.
- 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.
- map 390 comprises the identity of each device 310 , 320 on the CAN bus 330 .
- a truncated version of the map 390 may also be used and include only some of the devices.
- 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.
- 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 .
- 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.
- a distributed controller operatively associated with the added device may issue a signal with its device address.
- map 390 may be updated with the identity of the added device.
- map 390 may be updated to indicate that the non-responsive device has been removed from the CAN bus 330 , or is otherwise offline.
- the bridge and/or distributed controllers may also be used to assign a dynamic address to an added device.
- 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).
- the dynamic address may be removed from map 390 when a device is removed from the CAN bus 330 .
- 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 .
- external link 360 may interface via a port provided on the CAN bus 330 .
- 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 .
- 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.
- 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 .
- the optional bus 331 may also be a CAN bus.
- building automation system 300 may comprise separate and/or dedicated busses 330 , 331 for different areas of the building and/or for different functions.
- 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 ).
- 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.
- 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).
- 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.
- 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.
- the automation devices may each comprise a device address 430 .
- Each device address 430 may be unique to the device.
- 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.
- no other automation device has the same device address 430 , thereby reducing the likelihood that the automation device is misidentified.
- 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).
- the device address 430 may be unique to a category of devices.
- 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.
- 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 .
- 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 ).
- 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 .
- 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).
- each keypad has a unique device address (e.g., device address 430 in FIG. 4 ) that is different than any other device.
- Keypad A may have device address “123ABC”
- Keypad B may have device address “123XYZ”
- Keypad C may have device address “456ABC”.
- each keypad is assigned a dynamic address (e.g., dynamic address 420 in FIG. 4 ) when it is provided in the building automation system.
- Keypad A is assigned dynamic address “10”
- Keypad B is assigned dynamic address “20”
- Keypad C is assigned dynamic address “10.”
- 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.
- System A and System B are both used in System A, and therefore are assigned dynamic addresses that are unique to System A to avoid being misidentified.
- 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 .
- 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. 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.
- Signals may also be addressed to all of the devices on the CAN bus 330 (e.g., by setting the address field to null).
- 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.
- 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 ).
- 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).
- an acknowledgement may be issued over the CAN bus 330 when a signal 500 is received by the device.
- 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.
- 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.
- the acknowledgement field may be a negative acknowledged or “NAK” message when the received signal(s) cannot be read or are otherwise unusable.
- 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 ).
- FIG. 6 is a high-level schematic diagram of yet another exemplary building automation system 600 , illustrating the use of CAN routers.
- building automation system 600 may comprise one or more automation devices 610 a - 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 610 f for remotely (or wirelessly) communicating with one or more remote receivers 615 .
- the automation devices 610 a - g 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).
- the building automation system 600 may include at least one CAN bus backbone.
- a CAN bus backbone provides localized wiring, easing installation and troubleshooting.
- the CAN bus backbone is configured as subnets 620 and 625 .
- One or more bridges 630 a - b and 635 a - 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).
- a local area network 640 e.g., an Ethernet LAN
- 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 ).
- 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.
- operation of the subnet 620 may be switched from the primary bridge 630 a to the secondary bridge 630 b if the primary bridge fails.
- 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.
- CAN routers 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.
- one or more of the CAN routers 670 - 672 may be implemented as a hub.
- 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.
- 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.
- the router 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.
- 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.
- one or more of the CAN routers 670 - 672 may be implemented 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.
- 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.).
- 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.
- 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.
- 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 ).
- 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.
- I/O ports such as, e.g., power-in 720 , power-out 721 , CAN-in 722 , CAN-out 723 .
- I/O ports may also be provided (e.g., illustrated as in FIG. 7 “Port n” 725 ).
- other types of I/O ports may
- 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 ).
- 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.
- 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.
- 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 740 a - e, 741 a - 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.
- processors 730 - 734 may be linked to a plurality of device ports 740 a - e, 741 a - e, etc.
- the device ports may include standard connections, such as, e.g., RJ-45 ports to ease installation, device replacement, and reconfiguration.
- 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).
- Electrical power may be readily connected to the CAN router 700 , e.g., at port 720 , and provided to the processors 730 - 734 .
- an electrical power source may include local electrical wiring.
- 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 .
- Electrical power may also be provided to each of the automation devices from the CAN router 700 , e.g., via device ports 740 .
- electrical power may be provided directly to the automation device (e.g., using electrical wiring local to the automation devices).
- 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.
- CAN routers 800 - 802 means connecting a primary CAN router to the CAN backbone, and then connecting other CAN routers to the device ports.
- 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
- CAN router 802 is connected in turn to CAN router 801 at one of the device ports 822 .
- 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.
- 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.
- 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 .
- additional CAN routers e.g., CAN router 805
- device ports e.g., device port 823
- electrical power may be provided to the CAN routers 801 - 802 via device port 821 .
- 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 .
- 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.
- 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.
- 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.
- 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.
- 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.
Abstract
Description
- 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.
- The described subject matter relates to building automation, and more particularly to Control Area Network (CAN) bus router for building automation systems.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
-
FIG. 1 is a high-level schematic diagram of an exemplary building ion system. -
FIG. 2 is an exemplary instruction table for use with in a building automation system. -
FIG. 3 is a high-level schematic diagram of another exemplary building automation system. -
FIG. 4 is a high-level schematic diagram of exemplary distributed controllers for a building automation system. -
FIG. 5 illustrates an exemplary signal which may be issued over a CAN bus in a building automation system. -
FIG. 6 is a high-level schematic diagram of yet another exemplary building automation system, illustrating the use of CAN routers. -
FIG. 7 is a high-level schematic diagram of an exemplary CAN router for use with a building automation system. -
FIG. 8 is an illustration of exemplary CAN routers implemented in an exemplary daisy-chain configuration. -
FIG. 9 is a high-level schematic diagram of another exemplary CAN router for use with a building automation system. - 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.
- 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. - 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.
- 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.
- 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).
- 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.
-
FIG. 1 is a high-level schematic diagram of an exemplarybuilding automation system 100. Exemplarybuilding automation system 100 may comprise aCAN bus 130 for a number of automation devices. For example, one or more control devices 110-113 (also generally referred to herein ascontrol device 110 or control devices 110) may be operatively associated with theCAN bus 130. In addition, one or more controlled devices 120-124 (also generally referred to herein as controlleddevice 120 or controlled devices 120) may be operatively associated with the CANbus 130. - It is noted that suitable interfaces (not shown) may be provided for coupling the
control device 110 and controlleddevice 120 to theCAN bus 130 for issuing and receiving CAN signals over theCAN 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. - 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, thatCAN 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. - 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. -
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. - 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 theCAN bus 130, as will be described in more detail below. In other embodiments, controlleddevice 120 may also receive input from sources other than theCAN bus 130. - 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).
- 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 inFIG. 1 ascontrol device 110 and controlleddevice 120. That is, when the multi-function automation device performs the functions of a control device, it is represented inFIG. 1 ascontrol device 110. When the multi-function automation device performs the functions of a controlled device, it is represented inFIG. 1 as controlleddevice 120. - Continuing now with the description of exemplary
building automation system 100,control device 110 and controlleddevice 120 may be operatively associated with theCAN 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 controlleddevice 120 may be permanently linked to theCAN bus 130 by a hard-wire connection. Alternatively,control device 110 and/or controlleddevice 120 may be removably linked to theCAN bus 130 by a suitable “plug-type” connection (also referred to as a “bus tap”).Control device 110 and/or controlleddevice 120 may also be remotely (or wirelessly) linked to theCAN bus 130, for example via an RF link. -
Building automation system 100 may also comprise acentral controller 140 operatively associated with theCAN bus 130.Central controller 140 may also be linked to theCAN bus 130 in any suitable manner, such as described above forcontrol device 110 and controlleddevice 120. -
Central controller 140 may be any suitable device generally configured to receive a signal fromcontrol device 110 over theCAN bus 130, and in turn, to issue a signal with a corresponding instruction over theCAN bus 130 for controlleddevice 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 thecentral 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. - 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 thecontrol devices 110 and controlleddevices 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 theCAN bus 130. - 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. - 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 thebuilding automation system 100 by reducing the occurrence of corrupt or lost signals on theCAN bus 130. - As mentioned briefly above,
central controller 140 is configured to receive signals over the CAN bus fromcontrol device 110, and issue signals with corresponding instructions over the CAN bus for controlleddevice 120.Central controller 140 may access the instruction from an instruction table 150, as described in more detail below with reference toFIG. 2 . - 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 fromcentral 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). -
External link 160 may also be used to troubleshoot thebuilding automation system 100. For example, when an error occurs on theCAN bus 130, thecentral 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.). - Of course, it is understood that the
external link 160 is not limited to an ISP link. In other embodiments, theexternal 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, theexternal link 160 may comprise a link suitable for connecting a laptop computer to thebuilding automation system 100. -
Building automation system 100 may also comprise one or more optional repeater(s) 170, e.g., provided in-line on theCAN bus 130.Repeater 170 may be used to extend the physical length of theCAN bus 130, and/or increase the number of devices that can be provided on theCAN bus 130. For example,repeater 170 may amplify signals and/or “clean” (e.g., improve the signal to noise ratio) the signals issued overCAN bus 130. -
Building automation system 100 may also comprise one or moreadditional busses 131. In an exemplary embodiment, theoptional bus 131 is also a CAN bus. In an exemplary embodiment,building automation system 100 may comprisededicated busses Dedicated busses dedicated CAN bus 130 may be provided for all of the lighting devices and anotherdedicated CAN bus 131 may be provided for all of the security devices. Accordingly, a failure in oneCAN bus 130 does not affect operation of theother CAN bus 131. -
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., thecentral controller 140 and building automation system 4100 inFIG. 1 ). For example, the instruction table 200 may be stored on suitable computer readable storage media accessible by the central controller. - Exemplary instruction table 200 may comprise
signal data 205 andinstructions 210.Signal data 205 corresponds to the input which may be received by a central controller (e.g., thecentral controller 140 inFIG. 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). Theinstructions 210 identify functions that a controlled device (e.g., controlleddevice 120 inFIG. 1 ) may perform when the controlled device receives thecorresponding signal data 205. - By way of example, signal
data 205 may comprise Device ID=Device 1 and Input ID=Key 1. The instructions corresponding to thissignal data 205 may be “Main Lighting 50%” and “Perimeter Lighting ON”. In this example, ifDevice 1 issues a signal indicating thatKey 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). - 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. - 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 particularbuilding automation system 100 is known. - 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.
- With reference now to
FIGS. 1 and 2 , exemplarybuilding automation system 100 may be operated as follows.Control device 110 and/or controlleddevice 120 may be configured during manufacture, during installation, or when reconfiguring thebuilding automation system 100. Instruction table 200 is provided for use by thecontroller 140. Instruction table 200 may also be defined for thebuilding automation system 100. - 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 theCAN bus 130 for one or more controlleddevices 120. - In an exemplary embodiment, the signal(s) are broadcast by the
control device 110 over theCAN bus 130. That is, signals are received by each of the devices (110, 120, 140) on theCAN 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). - 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).
- In an exemplary embodiment, only the
central controller 140 responds to signal(s) fromcontrol device 110. Although each of the devices on theCAN bus 130 receive the signal fromcontrol device 110, none of the other devices respond. - The
central controller 140 receives the signal fromcontrol 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 inFIG. 2 are “Main Lighting 50%” and “Perimeter Lighting ON”. Thecentral controller 140 issues these instructions over theCAN bus 130. - In an exemplary embodiment, the
central controller 140 broadcasts a signal comprising the instructions over theCAN bus 130. The broadcast signal is received by each of the devices (110, 120, 140) on theCAN 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. - In the above example, one of the devices (e.g., controlled
device 122 inFIG. 1 ) may be a triac board for the main lighting circuit, and another of the automation devices (e.g., controlleddevice 123 inFIG. 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, controlleddevice 122 responds to the instruction “Main Lighting 50%” by dimming the main lighting circuit to 50%, and controlleddevice 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. - 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. - Exemplary Distributed Control Systems and Methods
-
FIG. 3 is a high-level schematic diagram of another exemplarybuilding automation system 300. Exemplarybuilding automation system 300 may include at least onecontrol device 310 and at least one controlleddevice 320 linked over CAN bus 330. It is noted that 300-series reference numbers are used to refer to the like elements shown inFIG. 1 and described above. - Exemplary
building automation system 300 may comprise distributed controller(s) (such as distributedcontroller 400 shown inFIG. 4 ) operatively associated with one or more of the automation devices. For example, distributed controller(s) may be provided for eachcontrol device 310, for each controlleddevice 320, or for bothcontrol devices 310 and controlleddevices 320. -
Building automation system 300 may also comprise one ormore 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 thebridge 380. Themap 390 may also be operatively associated with one or more of the distributed controllers. -
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, thatmap 390 is not limited to any particular format. - In an exemplary embodiment,
map 390 comprises the identity of eachdevice map 390 may also be used and include only some of the devices. For example, the truncated version ofmap 390 stored at a controlleddevice 320 may only identifycontrol devices 310 from which the controlleddevice 320 will receive signals. As another example, truncated versions of themap 390 may be provided atbridges 380 where thebuilding automation system 300 has more than onebridge 380. Eachbridge 380 is provided with atruncated map 390 identifying only devices on the CAN bus 330 that are linked to aparticular bridge 380. - 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 thedevices device bridge 380 and/or distributedcontrollers 400 automatically determine the status of thedevices 310/210 on the CAN bus (i.e., whether a device has been added or removed).Bridge 380 and/or distributedcontrollers 400 may update themaps 390 to reflect any changes. - By way of example, when a
device 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 adevice - 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 themap 390 accordingly. Thebridge 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 frommap 390 when a device is removed from the CAN bus 330. -
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 thecontrol devices 310, controlleddevices 320, and/orbridge 380. Alternatively, external link 360 may interface via a port provided on the CAN bus 330. As discussed above with reference toFIG. 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 thebuilding automation system 300. -
Building automation system 300 may also comprise anoptional 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 toFIG. 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. -
Building automation system 300 may also comprise one or moreadditional busses 331, which may be linked to one another viabridge 380 as shown inFIG. 3 . Although not required, theoptional bus 331 may also be a CAN bus. As discussed above,building automation system 300 may comprise separate and/ordedicated busses 330, 331 for different areas of the building and/or for different functions. -
FIG. 4 is a high-level schematic diagram of exemplary distributed controllers for a building automation system. Distributedcontroller 400 may be any suitable device configured to process signals (such as thesignal 500 shown inFIG. 5 ). In an exemplary embodiment, distributedcontroller 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 distributedcontroller 400. One or more of the distributedcontrollers 400 may also perform error checking and bus arbitration functions for the CAN bus. - Exemplary distributed
controllers 400 may comprise one or more microprocessors, PLAs (e.g., FPGA, ASIC), etc. It is noted that distributedcontrollers 400 may be operatively associated with automation devices, such as,control device 310 and/or controlleddevice 320, in any suitable manner. In an exemplary embodiment, distributedcontrollers 400 are provided at, and are directly linked to the automation device (e.g., as part of the same computer board). - 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 thebuilding automation system 300 may continue in operation even though one or more of the distributedcontrollers 400 is no longer operational. - In operation, distributed
controller 400 may generate signals. For example, distributedcontroller 400 may generate a signal comprising an instruction. That is, whencontrol device 310 receives input, distributedcontroller 400 may use instruction table 410 to generate a signal comprising corresponding instruction(s) for controlled device. Likewise, distributedcontroller 400 may perform any number of functions for the controlled device. In an exemplary embodiment, distributedcontroller 400 generates instructions for controlled device based on signals that are received over the CAN bus. - In an exemplary embodiment, the automation devices may each comprise a
device address 430. Eachdevice 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. Thedevice 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 thesame 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). - 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 thesame device address 430, which is different from thedevice 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. -
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 anaddress field 510. Accordingly, thesignals 500 may be addressed to specific automation devices, supporting so called “peer-to-peer” communication over the CAN bus even though thesignal 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 theaddress field 510 perform a reset instruction in field 520). - Although the
device address 430 itself may be provided in theaddress field 510 of thesignal 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, alarge address field 510 may reduce the size that can be allotted to other fields (e.g., to instruction field 520). In addition, asignal 500 having alarge 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. - In an exemplary embodiment, dynamic addressing may be implemented (e.g.,
dynamic address 420 inFIG. 4 ) for each automation device or category of devices. That is, each automation (or category of devices) may be assigned adynamic address 420 that is unique to a particular building automation system. Thedynamic address 420 may be shorter than thedevice 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). - 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 inFIG. 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 inFIG. 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. - With reference now to
FIGS. 3-5 , exemplarybuilding automation system 300 may be operated as follows. The distributedcontroller 400 processes theaddress field 510 of thesignal 500 to determine whether it is addressed to thedevice signal 500 may be broadcast over the CAN bus 330 to each of thedevices - The distributed
controllers 400 read the address in theaddress field 510 and determine whether it corresponds to thedevice address 430. If the address in theaddress field 510 does not correspond to thedevice address 430, thedevice controller 400 stops processing thesignal 500, thereby conserving processing power and increasing the efficiency of thebuilding automation system 300. If the address in theaddress field 510 corresponds to thedevice address 430, thecontroller 400 continues processing thesignal 500. Again, it is noted that more than one device may respond to a signal. - 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, asignal 500 may be addressed to groups of devices by including a group identification in theaddress field 510 or another field (e.g., Field n 540). For example, asignal 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). - 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. - In alternative exemplary embodiment, the distributed
controller 400 of a receiving device may issue a targeted acknowledgement, by returning asignal 500 with anacknowledgement 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). - Exemplary CAN Routers
-
FIG. 6 is a high-level schematic diagram of yet another exemplarybuilding automation system 600, illustrating the use of CAN routers. As discussed above with reference toFIGS. 1 and 3 ,building automation system 600 may comprise one or more automation devices 610 a-g, such as control devices (e.g., keypads) and/or controlled devices (e.g., motors). The automation devices may also include one or moreremote transmitters 610 f for remotely (or wirelessly) communicating with one or moreremote receivers 615. The automation devices 610 a-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). - 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 assubnets subnets - 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 thesubnet 620 may be switched from theprimary bridge 630 a to thesecondary bridge 630 b if the primary bridge fails. - The automation devices 610 may be communicatively coupled to the
CAN bus 660, 665 (e.g., in thesubnet - 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.).
- 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.
- 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 thebuilding automation system 100 described above with reference toFIG. 1 , thebuilding automation system 300 described above with reference toFIG. 3 , and with any other building automation system implementing a CAN bus. -
FIG. 7 is a high-level schematic diagram of anexemplary CAN router 700 for use with a building automation system (e.g.,building automation system Exemplary CAN router 700 may be connected in-line to the CAN bus backbone. A plurality of automation devices may be connected to theCAN router 700 for communications with other automation devices connected directly to theCAN 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 onLAN 640 inFIG. 6 ). -
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 inFIG. 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. -
Exemplary router 700 may also include a plurality of processors 730-734, each linked to the CAN bus backbone (e.g., between the CAN-inport 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. - 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.
- 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 740 a-e, 741 a-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.
- In an exemplary embodiment, processors 730-734 may be linked to a plurality of device ports 740 a-e, 741 a-e, etc. Although any suitable device ports 740 a-e, 741 a-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).
- Electrical power may be readily connected to the
CAN router 700, e.g., atport 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) viaport 721. - 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). -
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 theexemplary CAN router 700 shown inFIG. 7 . The CAN routers 800-802 may be connected to one another to expand device capacity without having to extend the CAN backbone. - 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 inFIG. 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. CANrouter 801 is connected toCAN router 800 at one of thedevice ports 821, andCAN router 802 is connected in turn toCAN router 801 at one of thedevice ports 822. - The
CAN routers 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 thatexpansion routers routers 700 inFIG. 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. - 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 theCAN router 800. - 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. - 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. - 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.
-
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 toFIG. 7 , and therefore are not repeated here. - 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. - 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 aCAN processor 910 connected to the CAN backbone, e.g., atconnection 915. CAN router 900 also includes cascading processors 920-923, serially linked to theCAN 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. - 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.
Claims (21)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/216,685 US20050288823A1 (en) | 2003-03-05 | 2005-08-31 | Can bus router for building automation systems |
US11/305,793 US7433740B2 (en) | 2003-03-05 | 2005-12-16 | CAN communication for building automation systems |
US12/247,163 US7650323B2 (en) | 2003-03-05 | 2008-10-07 | CAN communication for building automation system |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/382,979 US20040176877A1 (en) | 2003-03-05 | 2003-03-05 | Building automation system and method |
US11/216,685 US20050288823A1 (en) | 2003-03-05 | 2005-08-31 | Can bus router for building automation systems |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/382,979 Continuation-In-Part US20040176877A1 (en) | 2003-03-05 | 2003-03-05 | Building automation system and method |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/305,793 Continuation-In-Part US7433740B2 (en) | 2003-03-05 | 2005-12-16 | CAN communication for building automation systems |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050288823A1 true US20050288823A1 (en) | 2005-12-29 |
Family
ID=32926998
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/382,979 Abandoned US20040176877A1 (en) | 2003-03-05 | 2003-03-05 | Building automation system and method |
US11/216,685 Abandoned US20050288823A1 (en) | 2003-03-05 | 2005-08-31 | Can bus router for building automation systems |
US12/247,163 Expired - Fee Related US7650323B2 (en) | 2003-03-05 | 2008-10-07 | CAN communication for building automation system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/382,979 Abandoned US20040176877A1 (en) | 2003-03-05 | 2003-03-05 | Building automation system and method |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/247,163 Expired - Fee Related US7650323B2 (en) | 2003-03-05 | 2008-10-07 | CAN communication for building automation system |
Country Status (2)
Country | Link |
---|---|
US (3) | US20040176877A1 (en) |
WO (1) | WO2004079461A2 (en) |
Cited By (69)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050044275A1 (en) * | 2003-07-30 | 2005-02-24 | Adamson Hugh P. | Global and local command circuits for network devices |
US20050049754A1 (en) * | 2003-08-29 | 2005-03-03 | Craig Ogawa | Power and data configurations for building automation systems |
US20050049730A1 (en) * | 2003-08-29 | 2005-03-03 | Adamson Hugh P. | Keypad for building automation |
EP1898281A2 (en) * | 2006-08-30 | 2008-03-12 | Siemens Building Technologies, Inc. | Binding wireless devices in a building automation system |
US20080188367A1 (en) * | 2003-05-07 | 2008-08-07 | Saint-Gobain Glass France | Silico-sodo-calcic glass composition for the production of substrates |
US20100057943A1 (en) * | 2008-08-28 | 2010-03-04 | Robert Bosch Gmbh | System and method for connecting a security system using a network |
US20110026535A1 (en) * | 2005-11-29 | 2011-02-03 | Daisuke Ajitomi | Bridge apparatus and bridge system |
US20110213867A1 (en) * | 2010-02-26 | 2011-09-01 | Mccoy Sean | Simultaneous connectivity and management across multiple building automation system networks |
USD648641S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
USD648642S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
US8239066B2 (en) | 2008-10-27 | 2012-08-07 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
DE102011010041A1 (en) * | 2011-02-07 | 2012-08-09 | Göpel electronic GmbH | Modular controller area network-switch for controlling number of samples during manufacturing of electronic components interconnected in circuit at vehicle, has logic module control-technically influenced by master controller area network |
US8255086B2 (en) | 2008-10-27 | 2012-08-28 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US8260444B2 (en) | 2010-02-17 | 2012-09-04 | Lennox Industries Inc. | Auxiliary controller of a HVAC system |
US8295981B2 (en) | 2008-10-27 | 2012-10-23 | Lennox Industries Inc. | Device commissioning in a heating, ventilation and air conditioning network |
US8352081B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8352080B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8433446B2 (en) | 2008-10-27 | 2013-04-30 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8437877B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US8437878B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8442693B2 (en) | 2008-10-27 | 2013-05-14 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8452456B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8452906B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8463443B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
US8463442B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8543243B2 (en) | 2008-10-27 | 2013-09-24 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8548630B2 (en) | 2008-10-27 | 2013-10-01 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8560125B2 (en) | 2008-10-27 | 2013-10-15 | Lennox Industries | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8564400B2 (en) | 2008-10-27 | 2013-10-22 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8600558B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US8600559B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | Method of controlling equipment in a heating, ventilation and air conditioning network |
US8615326B2 (en) | 2008-10-27 | 2013-12-24 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8655491B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8655490B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8661165B2 (en) | 2008-10-27 | 2014-02-25 | Lennox Industries, Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
US8694164B2 (en) | 2008-10-27 | 2014-04-08 | Lennox Industries, Inc. | Interactive user guidance interface for a heating, ventilation and air conditioning system |
US8725298B2 (en) | 2008-10-27 | 2014-05-13 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network |
US8744629B2 (en) | 2008-10-27 | 2014-06-03 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8762666B2 (en) | 2008-10-27 | 2014-06-24 | Lennox Industries, Inc. | Backup and restoration of operation control data in a heating, ventilation and air conditioning network |
US8775689B2 (en) | 2011-05-02 | 2014-07-08 | Deere & Company | Electronic modules with automatic configuration |
US8774210B2 (en) | 2008-10-27 | 2014-07-08 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8788100B2 (en) | 2008-10-27 | 2014-07-22 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
US8798796B2 (en) | 2008-10-27 | 2014-08-05 | Lennox Industries Inc. | General control techniques in a heating, ventilation and air conditioning network |
US8802981B2 (en) | 2008-10-27 | 2014-08-12 | Lennox Industries Inc. | Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system |
US8855825B2 (en) | 2008-10-27 | 2014-10-07 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8874815B2 (en) | 2008-10-27 | 2014-10-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network |
US8892797B2 (en) | 2008-10-27 | 2014-11-18 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8977794B2 (en) | 2008-10-27 | 2015-03-10 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8994539B2 (en) | 2008-10-27 | 2015-03-31 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US9152155B2 (en) | 2008-10-27 | 2015-10-06 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US20150362896A1 (en) * | 2014-06-17 | 2015-12-17 | Crestron Electronics, Inc. | Shading Control Network Using a Control Network |
US20160028687A1 (en) * | 2014-07-25 | 2016-01-28 | David Sheppard | Internet Security Assembly |
US9261888B2 (en) | 2008-10-27 | 2016-02-16 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US9268345B2 (en) | 2008-10-27 | 2016-02-23 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US9325517B2 (en) | 2008-10-27 | 2016-04-26 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US9377768B2 (en) | 2008-10-27 | 2016-06-28 | Lennox Industries Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
US9432208B2 (en) | 2008-10-27 | 2016-08-30 | Lennox Industries Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
AU2011298473B2 (en) * | 2010-08-30 | 2017-03-16 | Tridonic Gmbh & Co Kg | Parallel programming and updating of lighting bus subscribers |
US9632490B2 (en) | 2008-10-27 | 2017-04-25 | Lennox Industries Inc. | System and method for zoning a distributed architecture heating, ventilation and air conditioning network |
US9651925B2 (en) | 2008-10-27 | 2017-05-16 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
US9678486B2 (en) | 2008-10-27 | 2017-06-13 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US20170223808A1 (en) * | 2014-08-11 | 2017-08-03 | RAB Lighting Inc. | Commissioning a configurable user control device for a lighting control system |
US10032364B2 (en) * | 2014-05-15 | 2018-07-24 | Savant Systems, Llc | Standalone wireless lighting application |
US10039174B2 (en) | 2014-08-11 | 2018-07-31 | RAB Lighting Inc. | Systems and methods for acknowledging broadcast messages in a wireless lighting control network |
US10085328B2 (en) | 2014-08-11 | 2018-09-25 | RAB Lighting Inc. | Wireless lighting control systems and methods |
CN109274568A (en) * | 2018-09-29 | 2019-01-25 | 广州致远电子有限公司 | A kind of processing method of CAN hub and data information |
US10202801B2 (en) | 2014-06-17 | 2019-02-12 | Crestron Electronics, Inc. | Shading and lighting control using a control network |
US10358869B2 (en) | 2014-06-17 | 2019-07-23 | Crestron Electronics, Inc. | Shading control network using a control network |
DE102018128095A1 (en) * | 2018-11-09 | 2020-05-14 | Lemken Gmbh & Co. Kg | Method for the simultaneous operation of several agricultural implements connected to one another for an application to form a combination of implements |
Families Citing this family (49)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040218591A1 (en) * | 2003-04-29 | 2004-11-04 | Craig Ogawa | Bridge apparatus and methods of operation |
US7799273B2 (en) * | 2004-05-06 | 2010-09-21 | Smp Logic Systems Llc | Manufacturing execution system for validation, quality and risk assessment and monitoring of pharmaceutical manufacturing processes |
US7444197B2 (en) | 2004-05-06 | 2008-10-28 | Smp Logic Systems Llc | Methods, systems, and software program for validation and monitoring of pharmaceutical manufacturing processes |
CN1855920A (en) * | 2005-04-28 | 2006-11-01 | 西门子(中国)有限公司 | Communication on magnetic resonance system multi-point bus |
DE102005025573A1 (en) * | 2005-06-03 | 2006-12-07 | Ellenberger & Poensgen Gmbh | Multiplexing system for boats or caravans |
US20070016870A1 (en) * | 2005-07-15 | 2007-01-18 | Microsoft Corporation | Control panel framework |
US8209398B2 (en) | 2006-03-16 | 2012-06-26 | Exceptional Innovation Llc | Internet protocol based media streaming solution |
US8725845B2 (en) | 2006-03-16 | 2014-05-13 | Exceptional Innovation Llc | Automation control system having a configuration tool |
US8001219B2 (en) | 2006-03-16 | 2011-08-16 | Exceptional Innovation, Llc | User control interface for convergence and automation system |
US7966083B2 (en) | 2006-03-16 | 2011-06-21 | Exceptional Innovation Llc | Automation control system having device scripting |
US8155142B2 (en) | 2006-03-16 | 2012-04-10 | Exceptional Innovation Llc | Network based digital access point device |
US8271881B2 (en) | 2006-04-20 | 2012-09-18 | Exceptional Innovation, Llc | Touch screen for convergence and automation system |
US7667968B2 (en) | 2006-05-19 | 2010-02-23 | Exceptional Innovation, Llc | Air-cooling system configuration for touch screen |
WO2008073658A2 (en) | 2006-11-09 | 2008-06-19 | Exceptional Innovation, Llc. | Portable device for convergence and automation solution |
CN101843033B (en) * | 2007-08-28 | 2013-11-13 | Abb研究有限公司 | Real-time communication security for automation networks |
US7915837B2 (en) * | 2008-04-08 | 2011-03-29 | Lumetric, Inc. | Modular programmable lighting ballast |
US8364319B2 (en) * | 2008-04-21 | 2013-01-29 | Inncom International Inc. | Smart wall box |
US8143811B2 (en) * | 2008-06-25 | 2012-03-27 | Lumetric, Inc. | Lighting control system and method |
US20100262296A1 (en) * | 2008-06-25 | 2010-10-14 | HID Laboratories, Inc. | Lighting control system and method |
US8713697B2 (en) | 2008-07-09 | 2014-04-29 | Lennox Manufacturing, Inc. | Apparatus and method for storing event information for an HVAC system |
US8527096B2 (en) | 2008-10-24 | 2013-09-03 | Lennox Industries Inc. | Programmable controller and a user interface for same |
WO2010095087A1 (en) * | 2009-02-19 | 2010-08-26 | Koninklijke Philips Electronics N.V. | Lighting control network |
US8296488B2 (en) | 2009-04-27 | 2012-10-23 | Abl Ip Holding Llc | Automatic self-addressing method for wired network nodes |
US11269303B2 (en) | 2009-06-22 | 2022-03-08 | Johnson Controls Technology Company | Systems and methods for detecting changes in energy usage in a building |
US9606520B2 (en) | 2009-06-22 | 2017-03-28 | Johnson Controls Technology Company | Automated fault detection and diagnostics in a building management system |
US9286582B2 (en) | 2009-06-22 | 2016-03-15 | Johnson Controls Technology Company | Systems and methods for detecting changes in energy usage in a building |
US8731724B2 (en) | 2009-06-22 | 2014-05-20 | Johnson Controls Technology Company | Automated fault detection and diagnostics in a building management system |
US9196009B2 (en) | 2009-06-22 | 2015-11-24 | Johnson Controls Technology Company | Systems and methods for detecting changes in energy usage in a building |
US10739741B2 (en) | 2009-06-22 | 2020-08-11 | Johnson Controls Technology Company | Systems and methods for detecting changes in energy usage in a building |
US8600556B2 (en) | 2009-06-22 | 2013-12-03 | Johnson Controls Technology Company | Smart building manager |
US8788097B2 (en) * | 2009-06-22 | 2014-07-22 | Johnson Controls Technology Company | Systems and methods for using rule-based fault detection in a building management system |
JP2013517565A (en) * | 2010-01-12 | 2013-05-16 | グーグル インコーポレイテッド | Operating system automatic update procedure |
CN102331765A (en) * | 2011-08-03 | 2012-01-25 | 中山大学深圳研究院 | Embedded digital household monitoring system |
CN102331764A (en) * | 2011-08-03 | 2012-01-25 | 中山大学深圳研究院 | Method and device for intelligently monitoring household based on CAN (Controller Area Network) bus |
US9313042B2 (en) * | 2011-10-18 | 2016-04-12 | Schneider Electric Buildings, Llc | Self-healing communications network |
JP5852267B2 (en) * | 2011-12-26 | 2016-02-03 | アーベーベー・リサーチ・リミテッドAbb Research Ltd. | Relay interface module for distributed control systems |
US9390388B2 (en) | 2012-05-31 | 2016-07-12 | Johnson Controls Technology Company | Systems and methods for measuring and verifying energy usage in a building |
US9749177B2 (en) * | 2012-09-21 | 2017-08-29 | Philips Lighting Holding B.V. | Method and apparatus for dynamic address assignment |
US20160033948A1 (en) * | 2013-03-07 | 2016-02-04 | Pioneer Corporation | Control system |
US9244753B2 (en) | 2013-03-15 | 2016-01-26 | Siemens Schweiz Ag | Redundant bus fault detection |
US10025279B2 (en) * | 2013-06-18 | 2018-07-17 | NuLEDs, Inc. | Controlling loads and collecting building information via IP networks |
US20150177720A1 (en) * | 2013-09-24 | 2015-06-25 | Anuva Automation, Inc. | Building automation system and method |
EP2911128A1 (en) * | 2014-02-24 | 2015-08-26 | Siemens Schweiz AG | Hazard warning assembly |
US9841210B2 (en) | 2014-04-22 | 2017-12-12 | Trane International Inc. | Sound level control in an HVAC system |
US10372092B2 (en) * | 2014-04-22 | 2019-08-06 | Trane International Inc. | System and method for controlling HVAC equipment so as to obtain a desired range of a sound pressure level and/or sound power level |
US9892073B1 (en) * | 2014-10-06 | 2018-02-13 | Master Lock Company Llc | Bus addressing systems and methods using repurposed bits |
CN110521285A (en) | 2017-04-10 | 2019-11-29 | 昕诺飞控股有限公司 | System and method for improving the data rate on addressable lighting network |
US10884966B2 (en) | 2018-12-04 | 2021-01-05 | Palo Alto Research Center Incorporated | Method and apparatus to prevent a node device from transmitting an unallowable message onto a CAN bus |
CN110719218B (en) * | 2019-10-31 | 2021-07-30 | 天津亚东智鑫科技有限公司 | Multi-node interconnection protocol standard method based on CAN bus |
Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5510975A (en) * | 1994-07-01 | 1996-04-23 | Atlantic Software, Inc. | Method of logical operations in home automation |
US5528215A (en) * | 1994-05-31 | 1996-06-18 | Landis & Gyr Powers, Inc. | Building automation system having expansion modules |
US5551053A (en) * | 1994-02-28 | 1996-08-27 | Eaton Corporation | System and Method for assigning addresses to I/O devices in a control network and for verifying the assigned address of the devices |
US5579221A (en) * | 1993-12-31 | 1996-11-26 | Samsung Electronics Co., Ltd. | Home automation system having user controlled definition function |
US5621662A (en) * | 1994-02-15 | 1997-04-15 | Intellinet, Inc. | Home automation system |
US5703442A (en) * | 1996-04-29 | 1997-12-30 | Electronic Lighting Incorporated | Method and apparatus for interfacing a light dimming control with an automated control system |
US5784547A (en) * | 1995-03-16 | 1998-07-21 | Abb Patent Gmbh | Method for fault-tolerant communication under strictly real-time conditions |
US5938757A (en) * | 1989-06-02 | 1999-08-17 | Ludo Arden Bertsch | Programmable distributed appliance control system |
US5940387A (en) * | 1995-11-22 | 1999-08-17 | Samsung Information Systems America | Home multimedia network architecture |
US6038500A (en) * | 1997-03-12 | 2000-03-14 | Deere & Company | Computer/bus message system for vehicle drive control system |
US6192282B1 (en) * | 1996-10-01 | 2001-02-20 | Intelihome, Inc. | Method and apparatus for improved building automation |
US6199136B1 (en) * | 1998-09-02 | 2001-03-06 | U.S. Philips Corporation | Method and apparatus for a low data-rate network to be represented on and controllable by high data-rate home audio/video interoperability (HAVi) network |
US6263260B1 (en) * | 1996-05-21 | 2001-07-17 | Hts High Technology Systems Ag | Home and building automation system |
US6292862B1 (en) * | 1998-07-28 | 2001-09-18 | Siemens Aktiengesellschaft | Bridge module |
US6297724B1 (en) * | 1994-09-09 | 2001-10-02 | The Whitaker Corporation | Lighting control subsystem for use in system architecture for automated building |
US6336128B1 (en) * | 1997-11-03 | 2002-01-01 | Daimlerchrysler Ag | Data-processing-aided electronic control system for a motor vehicle |
US20020015407A1 (en) * | 2000-04-12 | 2002-02-07 | Infineon Technologies, Ag | Method for transmitting information by means of data packets and network for transmitting data |
US20030074511A1 (en) * | 2000-10-18 | 2003-04-17 | Festo Ag & Co. | Bus repeater |
US6609172B1 (en) * | 2000-04-20 | 2003-08-19 | Hewlett-Packard Development Company, L.P. | Breaking up a bus to determine the connection topology and dynamic addressing |
US6728268B1 (en) * | 1999-06-22 | 2004-04-27 | Trimble Navigation Ltd. | Method and system to connect internet protocol hosts via an application specific bus |
US20040218591A1 (en) * | 2003-04-29 | 2004-11-04 | Craig Ogawa | Bridge apparatus and methods of operation |
US20080313316A1 (en) * | 1999-04-29 | 2008-12-18 | Amx Llc | Internet control system communication protocol, method and computer program |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5572438A (en) | 1995-01-05 | 1996-11-05 | Teco Energy Management Services | Engery management and building automation system |
US6104963A (en) * | 1998-04-03 | 2000-08-15 | Johnson Controls Technology Company | Communication system for distributed-object building automation system |
US6832120B1 (en) * | 1998-05-15 | 2004-12-14 | Tridium, Inc. | System and methods for object-oriented control of diverse electromechanical systems using a computer network |
US6437692B1 (en) | 1998-06-22 | 2002-08-20 | Statsignal Systems, Inc. | System and method for monitoring and controlling remote devices |
US6914893B2 (en) | 1998-06-22 | 2005-07-05 | Statsignal Ipc, Llc | System and method for monitoring and controlling remote devices |
US7103511B2 (en) * | 1998-10-14 | 2006-09-05 | Statsignal Ipc, Llc | Wireless communication networks for providing remote monitoring of devices |
US6813525B2 (en) * | 2000-02-25 | 2004-11-02 | Square D Company | Energy management system |
US7058508B2 (en) | 2001-01-12 | 2006-06-06 | Energy Control Technologies | Automated building service broker |
US7380210B2 (en) * | 2001-07-20 | 2008-05-27 | Siemens Building Technologies, Inc. | User interface with installment mode |
US7346463B2 (en) * | 2001-08-09 | 2008-03-18 | Hunt Technologies, Llc | System for controlling electrically-powered devices in an electrical network |
US7349761B1 (en) * | 2002-02-07 | 2008-03-25 | Cruse Mike B | System and method for distributed facility management and operational control |
KR100701110B1 (en) * | 2002-03-28 | 2007-03-30 | 로버트쇼 컨트롤즈 캄파니 | Energy management system and method |
US7383158B2 (en) * | 2002-04-16 | 2008-06-03 | Trane International Inc. | HVAC service tool with internet capability |
GB0211644D0 (en) | 2002-05-21 | 2002-07-03 | Wesby Philip B | System and method for remote asset management |
US7024282B2 (en) * | 2002-09-26 | 2006-04-04 | Siemens Building Technologies, Inc. | Multi-node utilization of a single network variable input for computation of a single control variable at a sink node |
US7433740B2 (en) * | 2003-03-05 | 2008-10-07 | Colorado Vnet, Llc | CAN communication for building automation systems |
US7089066B2 (en) | 2003-04-24 | 2006-08-08 | Colorado Vnet, Llc | Distributed control systems and methods |
US6967565B2 (en) | 2003-06-27 | 2005-11-22 | Hx Lifespace, Inc. | Building automation system |
US7502768B2 (en) * | 2004-02-27 | 2009-03-10 | Siemens Building Technologies, Inc. | System and method for predicting building thermal loads |
US7139239B2 (en) | 2004-10-05 | 2006-11-21 | Siemens Building Technologies, Inc. | Self-healing control network for building automation systems |
-
2003
- 2003-03-05 US US10/382,979 patent/US20040176877A1/en not_active Abandoned
-
2004
- 2004-02-27 WO PCT/US2004/005915 patent/WO2004079461A2/en active Application Filing
-
2005
- 2005-08-31 US US11/216,685 patent/US20050288823A1/en not_active Abandoned
-
2008
- 2008-10-07 US US12/247,163 patent/US7650323B2/en not_active Expired - Fee Related
Patent Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5938757A (en) * | 1989-06-02 | 1999-08-17 | Ludo Arden Bertsch | Programmable distributed appliance control system |
US5579221A (en) * | 1993-12-31 | 1996-11-26 | Samsung Electronics Co., Ltd. | Home automation system having user controlled definition function |
US5621662A (en) * | 1994-02-15 | 1997-04-15 | Intellinet, Inc. | Home automation system |
US5551053A (en) * | 1994-02-28 | 1996-08-27 | Eaton Corporation | System and Method for assigning addresses to I/O devices in a control network and for verifying the assigned address of the devices |
US5528215A (en) * | 1994-05-31 | 1996-06-18 | Landis & Gyr Powers, Inc. | Building automation system having expansion modules |
US5510975A (en) * | 1994-07-01 | 1996-04-23 | Atlantic Software, Inc. | Method of logical operations in home automation |
US6297724B1 (en) * | 1994-09-09 | 2001-10-02 | The Whitaker Corporation | Lighting control subsystem for use in system architecture for automated building |
US5784547A (en) * | 1995-03-16 | 1998-07-21 | Abb Patent Gmbh | Method for fault-tolerant communication under strictly real-time conditions |
US5940387A (en) * | 1995-11-22 | 1999-08-17 | Samsung Information Systems America | Home multimedia network architecture |
US5703442A (en) * | 1996-04-29 | 1997-12-30 | Electronic Lighting Incorporated | Method and apparatus for interfacing a light dimming control with an automated control system |
US6263260B1 (en) * | 1996-05-21 | 2001-07-17 | Hts High Technology Systems Ag | Home and building automation system |
US6192282B1 (en) * | 1996-10-01 | 2001-02-20 | Intelihome, Inc. | Method and apparatus for improved building automation |
US6038500A (en) * | 1997-03-12 | 2000-03-14 | Deere & Company | Computer/bus message system for vehicle drive control system |
US6336128B1 (en) * | 1997-11-03 | 2002-01-01 | Daimlerchrysler Ag | Data-processing-aided electronic control system for a motor vehicle |
US6292862B1 (en) * | 1998-07-28 | 2001-09-18 | Siemens Aktiengesellschaft | Bridge module |
US6199136B1 (en) * | 1998-09-02 | 2001-03-06 | U.S. Philips Corporation | Method and apparatus for a low data-rate network to be represented on and controllable by high data-rate home audio/video interoperability (HAVi) network |
US20080313316A1 (en) * | 1999-04-29 | 2008-12-18 | Amx Llc | Internet control system communication protocol, method and computer program |
US6728268B1 (en) * | 1999-06-22 | 2004-04-27 | Trimble Navigation Ltd. | Method and system to connect internet protocol hosts via an application specific bus |
US20020015407A1 (en) * | 2000-04-12 | 2002-02-07 | Infineon Technologies, Ag | Method for transmitting information by means of data packets and network for transmitting data |
US6609172B1 (en) * | 2000-04-20 | 2003-08-19 | Hewlett-Packard Development Company, L.P. | Breaking up a bus to determine the connection topology and dynamic addressing |
US20030074511A1 (en) * | 2000-10-18 | 2003-04-17 | Festo Ag & Co. | Bus repeater |
US20040218591A1 (en) * | 2003-04-29 | 2004-11-04 | Craig Ogawa | Bridge apparatus and methods of operation |
Cited By (88)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080188367A1 (en) * | 2003-05-07 | 2008-08-07 | Saint-Gobain Glass France | Silico-sodo-calcic glass composition for the production of substrates |
US20050044275A1 (en) * | 2003-07-30 | 2005-02-24 | Adamson Hugh P. | Global and local command circuits for network devices |
US20050049754A1 (en) * | 2003-08-29 | 2005-03-03 | Craig Ogawa | Power and data configurations for building automation systems |
US20050049730A1 (en) * | 2003-08-29 | 2005-03-03 | Adamson Hugh P. | Keypad for building automation |
US20110026535A1 (en) * | 2005-11-29 | 2011-02-03 | Daisuke Ajitomi | Bridge apparatus and bridge system |
US9258137B2 (en) * | 2005-11-29 | 2016-02-09 | Kabushiki Kaisha Toshiba | Bridge apparatus and bridge system with a virtual device for protocol conversion |
EP1898281A2 (en) * | 2006-08-30 | 2008-03-12 | Siemens Building Technologies, Inc. | Binding wireless devices in a building automation system |
US20080125057A1 (en) * | 2006-08-30 | 2008-05-29 | Geoffrey Daniel Nass | Binding wireless devices in a building automation system |
EP1898281B1 (en) * | 2006-08-30 | 2011-04-20 | Siemens Industry, Inc. | Binding wireless devices in a building automation system |
US8023440B2 (en) * | 2006-08-30 | 2011-09-20 | Siemens Industry, Inc. | Binding wireless devices in a building automation system |
US8412789B2 (en) | 2008-08-28 | 2013-04-02 | Robert Bosch Gmbh | System and method for connecting a security system using a network |
US20100057943A1 (en) * | 2008-08-28 | 2010-03-04 | Robert Bosch Gmbh | System and method for connecting a security system using a network |
US8798796B2 (en) | 2008-10-27 | 2014-08-05 | Lennox Industries Inc. | General control techniques in a heating, ventilation and air conditioning network |
US8694164B2 (en) | 2008-10-27 | 2014-04-08 | Lennox Industries, Inc. | Interactive user guidance interface for a heating, ventilation and air conditioning system |
US9432208B2 (en) | 2008-10-27 | 2016-08-30 | Lennox Industries Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
US9377768B2 (en) | 2008-10-27 | 2016-06-28 | Lennox Industries Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
US9325517B2 (en) | 2008-10-27 | 2016-04-26 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8295981B2 (en) | 2008-10-27 | 2012-10-23 | Lennox Industries Inc. | Device commissioning in a heating, ventilation and air conditioning network |
US8352081B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8352080B2 (en) | 2008-10-27 | 2013-01-08 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US9268345B2 (en) | 2008-10-27 | 2016-02-23 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8433446B2 (en) | 2008-10-27 | 2013-04-30 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8437877B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US8437878B2 (en) | 2008-10-27 | 2013-05-07 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8442693B2 (en) | 2008-10-27 | 2013-05-14 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8452456B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8452906B2 (en) | 2008-10-27 | 2013-05-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8463443B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network |
US8463442B2 (en) | 2008-10-27 | 2013-06-11 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8543243B2 (en) | 2008-10-27 | 2013-09-24 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8548630B2 (en) | 2008-10-27 | 2013-10-01 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8560125B2 (en) | 2008-10-27 | 2013-10-15 | Lennox Industries | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8564400B2 (en) | 2008-10-27 | 2013-10-22 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8600558B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US8600559B2 (en) | 2008-10-27 | 2013-12-03 | Lennox Industries Inc. | Method of controlling equipment in a heating, ventilation and air conditioning network |
US8615326B2 (en) | 2008-10-27 | 2013-12-24 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8655491B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network |
US8655490B2 (en) | 2008-10-27 | 2014-02-18 | Lennox Industries, Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8661165B2 (en) | 2008-10-27 | 2014-02-25 | Lennox Industries, Inc. | Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system |
US9261888B2 (en) | 2008-10-27 | 2016-02-16 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8725298B2 (en) | 2008-10-27 | 2014-05-13 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network |
US8744629B2 (en) | 2008-10-27 | 2014-06-03 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US8761945B2 (en) | 2008-10-27 | 2014-06-24 | Lennox Industries Inc. | Device commissioning in a heating, ventilation and air conditioning network |
US8762666B2 (en) | 2008-10-27 | 2014-06-24 | Lennox Industries, Inc. | Backup and restoration of operation control data in a heating, ventilation and air conditioning network |
US8255086B2 (en) | 2008-10-27 | 2012-08-28 | Lennox Industries Inc. | System recovery in a heating, ventilation and air conditioning network |
US9678486B2 (en) | 2008-10-27 | 2017-06-13 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8774210B2 (en) | 2008-10-27 | 2014-07-08 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8788100B2 (en) | 2008-10-27 | 2014-07-22 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
US8239066B2 (en) | 2008-10-27 | 2012-08-07 | Lennox Industries Inc. | System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network |
US9632490B2 (en) | 2008-10-27 | 2017-04-25 | Lennox Industries Inc. | System and method for zoning a distributed architecture heating, ventilation and air conditioning network |
US8802981B2 (en) | 2008-10-27 | 2014-08-12 | Lennox Industries Inc. | Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system |
US8855825B2 (en) | 2008-10-27 | 2014-10-07 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US8874815B2 (en) | 2008-10-27 | 2014-10-28 | Lennox Industries, Inc. | Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network |
US8892797B2 (en) | 2008-10-27 | 2014-11-18 | Lennox Industries Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8977794B2 (en) | 2008-10-27 | 2015-03-10 | Lennox Industries, Inc. | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network |
US8994539B2 (en) | 2008-10-27 | 2015-03-31 | Lennox Industries, Inc. | Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network |
US9152155B2 (en) | 2008-10-27 | 2015-10-06 | Lennox Industries Inc. | Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system |
US9651925B2 (en) | 2008-10-27 | 2017-05-16 | Lennox Industries Inc. | System and method for zoning a distributed-architecture heating, ventilation and air conditioning network |
USD648642S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
USD648641S1 (en) | 2009-10-21 | 2011-11-15 | Lennox Industries Inc. | Thin cover plate for an electronic system controller |
US9574784B2 (en) | 2010-02-17 | 2017-02-21 | Lennox Industries Inc. | Method of starting a HVAC system having an auxiliary controller |
US8788104B2 (en) | 2010-02-17 | 2014-07-22 | Lennox Industries Inc. | Heating, ventilating and air conditioning (HVAC) system with an auxiliary controller |
US9599359B2 (en) | 2010-02-17 | 2017-03-21 | Lennox Industries Inc. | Integrated controller an HVAC system |
US8260444B2 (en) | 2010-02-17 | 2012-09-04 | Lennox Industries Inc. | Auxiliary controller of a HVAC system |
US8219660B2 (en) * | 2010-02-26 | 2012-07-10 | Trane International Inc. | Simultaneous connectivity and management across multiple building automation system networks |
US20110213867A1 (en) * | 2010-02-26 | 2011-09-01 | Mccoy Sean | Simultaneous connectivity and management across multiple building automation system networks |
AU2011298473B2 (en) * | 2010-08-30 | 2017-03-16 | Tridonic Gmbh & Co Kg | Parallel programming and updating of lighting bus subscribers |
DE102011010041A1 (en) * | 2011-02-07 | 2012-08-09 | Göpel electronic GmbH | Modular controller area network-switch for controlling number of samples during manufacturing of electronic components interconnected in circuit at vehicle, has logic module control-technically influenced by master controller area network |
DE102011010041B4 (en) | 2011-02-07 | 2019-04-25 | Göpel electronic GmbH | Modular CAN-SWITCH |
US8775689B2 (en) | 2011-05-02 | 2014-07-08 | Deere & Company | Electronic modules with automatic configuration |
US10032364B2 (en) * | 2014-05-15 | 2018-07-24 | Savant Systems, Llc | Standalone wireless lighting application |
US10202801B2 (en) | 2014-06-17 | 2019-02-12 | Crestron Electronics, Inc. | Shading and lighting control using a control network |
US9267327B2 (en) * | 2014-06-17 | 2016-02-23 | Crestron Electronics Inc. | Shading control network using a control network |
US20150362896A1 (en) * | 2014-06-17 | 2015-12-17 | Crestron Electronics, Inc. | Shading Control Network Using a Control Network |
US9366082B2 (en) * | 2014-06-17 | 2016-06-14 | Crestron Electronics Inc. | Shading control network using a control network |
US10920491B2 (en) | 2014-06-17 | 2021-02-16 | Crestron Electronics, Inc. | Shading and lighting control using a control network |
US10358869B2 (en) | 2014-06-17 | 2019-07-23 | Crestron Electronics, Inc. | Shading control network using a control network |
US20160028687A1 (en) * | 2014-07-25 | 2016-01-28 | David Sheppard | Internet Security Assembly |
US20170223808A1 (en) * | 2014-08-11 | 2017-08-03 | RAB Lighting Inc. | Commissioning a configurable user control device for a lighting control system |
US10219356B2 (en) | 2014-08-11 | 2019-02-26 | RAB Lighting Inc. | Automated commissioning for lighting control systems |
US10085328B2 (en) | 2014-08-11 | 2018-09-25 | RAB Lighting Inc. | Wireless lighting control systems and methods |
US10531545B2 (en) * | 2014-08-11 | 2020-01-07 | RAB Lighting Inc. | Commissioning a configurable user control device for a lighting control system |
US10855488B2 (en) | 2014-08-11 | 2020-12-01 | RAB Lighting Inc. | Scheduled automation associations for a lighting control system |
US10039174B2 (en) | 2014-08-11 | 2018-07-31 | RAB Lighting Inc. | Systems and methods for acknowledging broadcast messages in a wireless lighting control network |
US11398924B2 (en) | 2014-08-11 | 2022-07-26 | RAB Lighting Inc. | Wireless lighting controller for a lighting control system |
US11722332B2 (en) | 2014-08-11 | 2023-08-08 | RAB Lighting Inc. | Wireless lighting controller with abnormal event detection |
CN109274568A (en) * | 2018-09-29 | 2019-01-25 | 广州致远电子有限公司 | A kind of processing method of CAN hub and data information |
DE102018128095A1 (en) * | 2018-11-09 | 2020-05-14 | Lemken Gmbh & Co. Kg | Method for the simultaneous operation of several agricultural implements connected to one another for an application to form a combination of implements |
Also Published As
Publication number | Publication date |
---|---|
WO2004079461A3 (en) | 2005-09-15 |
WO2004079461A2 (en) | 2004-09-16 |
US7650323B2 (en) | 2010-01-19 |
US20040176877A1 (en) | 2004-09-09 |
US20090105846A1 (en) | 2009-04-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20050288823A1 (en) | Can bus router for building automation systems | |
US7433740B2 (en) | CAN communication for building automation systems | |
US6574234B1 (en) | Method and apparatus for controlling network devices | |
US7089066B2 (en) | Distributed control systems and methods | |
CN108432282B (en) | Method and apparatus for managing electronic devices through wireless communication | |
CA2661915C (en) | Method and device for binding an automation component within a building automation system | |
EP1783959B1 (en) | Self-healing control network for building automation systems | |
US8560125B2 (en) | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network | |
EP1390817B1 (en) | Network control system for home appliances | |
US8977794B2 (en) | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network | |
US8452906B2 (en) | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network | |
US20150084547A1 (en) | DALI commissioning tools and methods for implementing | |
US20100106810A1 (en) | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network | |
US20100115364A1 (en) | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network | |
US20100106325A1 (en) | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network | |
US20100106787A1 (en) | Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network | |
US20100106326A1 (en) | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network | |
JP2005538506A (en) | Master-slave oriented two-way RF wireless lighting control system | |
JP2003009261A (en) | System and method for building routing table and for routing signal in automation system | |
EP3245763B1 (en) | Adaptive recovery from node failures in a network system | |
US10667320B2 (en) | Network connectivity of a building control device | |
US20100074116A1 (en) | System and Method of Controlling a Wireless Radio-Frequency Network Using a Gateway Device | |
US11374784B2 (en) | Home-automation system for a building and building comprising such a home-automation system | |
US11271845B2 (en) | Method of communication implemented in a home-automation system for a building and associated home-automation system | |
US11063900B2 (en) | Method for communicating between communicating elements forming part of a home automation system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: COLORADO VNET, LLC, COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HESSE, SCOTT;NICOLAY, WILLIAM;ADAMSON, HUGH PATRICK;AND OTHERS;REEL/FRAME:016775/0815;SIGNING DATES FROM 20050826 TO 20050830 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: RUSSOUND ACQUISITION CORP., NEW HAMPSHIRE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:COLORADO VNET, LLC;REEL/FRAME:024823/0476 Effective date: 20100806 |
|
AS | Assignment |
Owner name: COLORADO VNET CORP., NEW HAMPSHIRE Free format text: CHANGE OF NAME;ASSIGNOR:RUSSOUND ACQUISITION CORP.;REEL/FRAME:024933/0412 Effective date: 20091015 |
|
AS | Assignment |
Owner name: 3VNET, INC., FLORIDA Free format text: CHANGE OF NAME;ASSIGNOR:COLORADO VNET CORP;REEL/FRAME:030111/0296 Effective date: 20120503 |
|
AS | Assignment |
Owner name: AUTOMATED CONTROL TECHNOLOGY PARTNERS, INC., FLORI Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:3VNET,INC.;REEL/FRAME:030460/0468 Effective date: 20130515 |
|
AS | Assignment |
Owner name: GOOGLE INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AUTOMATED CONTROL TECHNOLOGY PARTNERS, INC.;REEL/FRAME:031515/0743 Effective date: 20130819 |