US20060271204A1 - Hot Reprogrammability of Building Automation Devices - Google Patents
Hot Reprogrammability of Building Automation Devices Download PDFInfo
- Publication number
- US20060271204A1 US20060271204A1 US11/462,749 US46274906A US2006271204A1 US 20060271204 A1 US20060271204 A1 US 20060271204A1 US 46274906 A US46274906 A US 46274906A US 2006271204 A1 US2006271204 A1 US 2006271204A1
- Authority
- US
- United States
- Prior art keywords
- script
- building automation
- signal
- control
- automation
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40208—Bus networks characterized by the use of a particular bus standard
- H04L2012/40215—Controller Area Network CAN
Definitions
- 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.
- Computer networks are known in which a server computer issues a series of commands over an Ethernet network to an output device.
- the commands are complex data structures requiring the server computer to establish an elaborate communications protocol between the server computer and the output device, followed by the server transmitting multiple data packets containing the commands.
- Transmitting these commands consumes significant bandwidth on the network, especially when more than one command is issued to the same or multiple output devices at the same time or within a close timeframe. Network performance decreases, resulting in slow transmission speeds and sometimes even recognizable delays in the response time. Transmitting commands also increases the potential for data corruption resulting in failed operations. In addition, when the server computer fails, all of the devices on the network are “down.”
- FIG. 1 is a high-level schematic diagram of an exemplary distributed control system.
- FIG. 2 ( a ) and ( b ) are high-level schematic diagrams of an exemplary node that may be implemented in a distributed control system.
- FIG. 3 is an illustration of an exemplary signal that may be implemented in a distributed control system.
- FIG. 4 is a portion of one embodiment of a script which may be used with the distributed control system of the present invention.
- FIG. 5 is a flowchart illustrating exemplary operations in an exemplary distributed control system.
- distributed control systems are disclosed as it may be used in a building automation environment, although other uses are also contemplated as being within the scope of the invention (e.g., manufacturing, water supply monitoring, and a variety of other environments).
- distributed control system may be used to automate various functions (e.g., control one or more loads), such as, but not limited to, lighting, climate control, audio/visual output, and various monitoring systems (e.g., security), to name only a few examples.
- the distributed control systems may include a number of automation devices or “nodes” operatively associated with one another over one or more automation network(s).
- the nodes may comprise any of a wide variety of control and/or controlled devices now known or later developed.
- the nodes may be devices that respond to events (e.g., keypads, temperature sensors, timers, water-level sensors), devices that control various functions (e.g., lighting controls, motor controls), or a combination thereof.
- individual nodes may be programmed and reprogrammed without affecting the other nodes on the network, without interfering with the operation of other nodes or the building automation network, and without having to shut off or restart other nodes or the building automation network.
- the distributed control system may be readily modified for different and/or additional devices and functions at any time, either locally or directly at the node, or from a remote location by the user (e.g., a homeowner or service provider).
- the distributed control system may also be readily modified at any time, even after the initial installation, allowing automated functions to be readily tailored for the user's preferences.
- FIG. 1 is a high-level schematic diagram of any exemplary distributed control system.
- the distributed control system 100 may comprise a number of automation devices or “nodes” 110 .
- the nodes 110 are operatively associated with one another over one or more networks 130 (cumulatively referred to as the “automation network”), although it is understood that a “stand-alone” node may also be implemented.
- Nodes 110 may be linked to one another over various types of networks. According to one embodiment, nodes 110 are linked using a controller area network (CAN) bus.
- CAN controller area network
- Such an embodiment of building automation system 100 is described in more detail in co-pending, co-owned U.S. patent application Ser. No. 10/382,979, entitled “BUILDING AUTOMATION SYSTEM AND METHOD” of Hesse, et al., filed on Mar. 5, 2003, which is hereby incorporated herein by reference for all that it discloses.
- the CAN bus comprises 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 can be extended to about 10,000 meters at transmission speeds of about 5 kilobits per second (kbits/s) It is also a robust bus and can be operated in noisy electrical environments while maintaining the integrity of the data.
- Mbits/s Megabits per second
- kbits/s kilobits per second
- 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.
- the invention is not limited to any particular version and it is intended that other specification for the CAN bus now know or later developed are also contemplated as being within the scope of the invention.
- networks may also comprise an Ethernet or a wireless network (e.g., radio frequency (RF), BLUETOOTHTM, ZIGBEETM), to name only a few.
- the network 130 may comprise more than one network (e.g., 131), or subnets as they are sometimes referred to.
- the network may comprise a plurality of CAN bus subnets, each linked to one another by an Ethernet network. Bridging apparatus or bridge 180 may be provided to link the networks to one another.
- nodes 110 may be operatively associated with the network 130 in any suitable manner, including by permanent, removable, or remote link.
- nodes 110 may be permanently linked to the network 130 by a hard-wire connection.
- nodes 110 may be removably lined to the network by a “plug-type” connection.
- Nodes 110 may also be remotely linked to the network, for example via an RF link.
- Suitable interfaces may be provides for nodes 110 for issuing and receiving signals over the network 130 . Such interfaces can be readily provided by one skilled in the art after having become familiar with the teachings of the present invention.
- link 160 may comprise an external link from another network such as the Internet through an Internet service provider (ISP).
- ISP Internet service provider
- link 160 may comprise a link from another device on the same network (e.g., bridge 180 or server computer). Link 160 may be used to import/export the scripts 400 to the nodes 110 during installation or to configure or reconfigure one or more of the nodes 110 at a later time.
- link 160 is not limited to an ISP link.
- the link 160 may be via a local area network (LAN), a wide area network (WAN), an Intranet, a telephony link, a digital subscriber line (DSL), T-1 connection, cellular line, satellite link, etc.
- 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.
- link 160 may comprise a temporary connection for use by a service technician or the user.
- the link 160 may comprise a link for connecting a laptop computer to the network 130 .
- Nodes 110 may be any device or combination of devices generally configured to respond to an event.
- Nodes 110 may comprise, but are not limited to, keypads, knobs, sliders, touch-screens, graphical user interfaces (GUI), control systems (e.g., lighting control circuits, HVAC systems, security systems), personal computers (PC) and PC accessories, and other devices that are now known or later developed.
- GUI graphical user interfaces
- control systems e.g., lighting control circuits, HVAC systems, security systems
- PC personal computers
- nodes 110 may be operatively associated with, and receive input from external devices (e.g., clocks, water level sensors, temperature sensors, light sensors).
- FIGS. 2 ( a ) and ( b ) are high-level schematic diagrams of an exemplary node that may be implemented in a distributed control system.
- FIG 2 ( a ) shows one embodiment of an “unscripted” node 200 (e.g., a keypad).
- Unscripted node 200 may comprise a controller 210 operatively associated with the network 130 via network interface 220 .
- Controller 210 is preferably configured to respond to an event (e.g., receive input 230 ) by generating a signal 300 associated with the event (e.g., identifies the event).
- the signal 300 may also contain a field identifying an address of the source of the event.
- Controller 210 may be provided with computer-readable program code (e.g., firmware on computer readable storage 270 ).
- computer-readable program code may comprise program code for processing an event 212 and program code for generating and/or issuing a signal 214 . Accordingly, the controller 210 may respond to an event (e.g., by receiving input and generating a signal corresponding to the event).
- Controller 210 may also generate output 240 .
- output 240 may comprise lighting and LED light (e.g., indicating a pressed key on a keypad, a status light, etc.).
- controllers such as provided for unscripted node 200 that can perform one or more predetermined functions are well-known in the electronics art and may comprise, by way of example, one or more programmable logic devices (PLDs) such as a field programmable gate array (FPGA), application-specific integrated circuit (ASIC), or microprocessor, to name only a few.
- PLDs programmable logic devices
- FPGA field programmable gate array
- ASIC application-specific integrated circuit
- network interfaces 220 are also readily available and the selection of a suitable network interface will depend to some extent of the type of network 130 .
- Computer-readable storage 270 it is also well within the ability of one skilled in the art to provide computer-readable storage 270 for use with the present invention.
- Exemplary embodiments of computer-readable storage include, but are not limited to various types of programmable memory, read-only memory (ROM), random access memory (RAM), flash memory, magnetic storage, a combination thereof, etc. It is noted that the memory can also be an integral part of the controller. Further explanation of computer-readable storage 270 is not necessary for a complete understanding of the invention, and therefore is not described in further detail herein.
- Distributed controller 211 is preferably also configured to respond to an event. For example, distributed controller 211 may respond to signal 300 or other input received over network 130 . Distributed controller 211 may also generate output (e.g., issue a signal over network 130 ).
- Distributed controller 211 preferably comprises computer-readable program code (e.g., residing on computer-readable storage 270 ) for responding to signal 300 or other input.
- distributed controller 211 may comprise a signal filter 262 , program code for executing scripts 264 , and program code for controlling one or more loads 266 .
- Signal filter 262 may be provided to determine whether a signal 300 issued over the network 130 is intended for scripted node 250 . For example, signal filter 262 may compare the event associated with the signal to a one or more types of events that the scripted node 250 responds to (e.g., as defined by the script header).
- program code for executing the script may read the signal 300 and execute at least one script corresponding to the signal.
- Embodiments of scripts are described in more detail below. For now, it is enough to understand that the executed script(s) may perform a function, and preferably drives a load (e.g., turn on a lighting circuit).
- An unscripted node 200 may receive input and issue signals associated with the input to another node. Unscripted node 200 may receive signals from other nodes and issue a response or action such as, e.g., sending a signal indicating an LED state, or activating an LED. Likewise, a scripted node 250 may receive signals from other nodes and perform one or more functions (e.g., driving a load) corresponding to the signals as instructed by the executed script(s). However, it is understood that the nodes 110 are not limited only to these operations. For example, nodes 110 can be configured to receive input, issue signals and/or perform one or more functions (e.g., driving a load). Such a node, although not shown, may be readily provided by combining components from both embodiments shown in FIGS. 2 ( a ) and ( b ) and described above.
- nodes 110 may also be configured with other sources to receive input and/or send output, and are not limited to I/O operations only with other nodes 110 .
- nodes 110 may receive input directly from sensors or timers operatively associated with the nodes 110 , and send output to displays, data logs, etc.
- nodes 110 may be provided with various ancillary devices, for example, power supplies, electronic controls, input/output (I/O) devices, etc.
- ancillary devices for example, power supplies, electronic controls, input/output (I/O) devices, 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 invention.
- one or more of the nodes 110 respond to various events.
- events may include, but are not limited to a user pressing a key on a keypad, a clock indicating the time, a light sensor indicating the level of outdoor light, a water level sensor indicating the water level in a body of water, a flow control sensor indicating the flow of water, to name only a few.
- an unscripted node 200 may respond to an event by issuing a signal 300 (e.g., over network 130 ) to a scripted node 250 .
- a signal 300 e.g., over network 130
- an unscripted keypad may issue one or more signals in response to the user pressing a key (or sequence of keys).
- a scripted node 250 may issue a signal 300 to an unscripted node 200
- a scripted node 250 may issue a signal 300 to another scripted node 250 .
- FIG. 3 is an illustration of an exemplary signal that may be implemented in a distributed control system.
- Signal 300 may comprise one or more fields 310 - 330 .
- at least one of the fields comprises an Event ID field 320 which comprises an event identifier.
- Signal 300 may also comprise one or fields.
- signal 300 may comprise an address field 310 with the network address of one or more of the nodes 110 so that the signal 300 can be delivered to one or more addressed nodes in the network 130 .
- the node 110 generating signal 300 may issue redundant signals 300 .
- a redundant signal 300 preferably is a copy of the signal 300 , which may be issued over the network 130 sequentially, or at a later time (e.g., if the first signal is not received or is corrupted). Accordingly, if one of the signals 300 is misdirected, corrupted or otherwise unusable upon receipt by another device, the redundant signal is issued to the node 110 . Redundant signal 300 may be issued automatically (e.g., following a time-out) or at the request of one or more of the nodes 110 .
- signals 300 may be addressed to specific devices or categories of devices.
- signal 300 may be a global signal that is issued to all of the nodes 110 on the network 130 or one or more subnets 131 .
- signal 300 may be addressed to groups of nodes 110 , such as all the outdoor lighting, so that all of the functions associated with those nodes 110 can be controlled without the need for issuing separate signals to each node 110 .
- the node(s) receiving signal 300 may respond by executing at least one script to perform any one or more of a variety of functions.
- Script(s) 400 for performing various functions may be provided on the computer-readable storage 271 of a scripted node 250 and can be executed at the scripted node 250 by the distributed controller 211 .
- other messages can be received by the node 110 and processed locally without the use of a script.
- Executing the at least one script performs one or more functions, and preferably drives a load.
- the executed script(s) may activate or deactivate a load, and preferably even control one or more parameters of the load (e.g., slew rate or intensity in the case of lighting).
- the executed program code may turn on lighting (e.g., the load) to 50 % intensity by slewing over 30 seconds.
- buttons on a keypad can be defined to control one or more loads according to various parameters, and later the same buttons can be defined to control one or more different loads, and/or to control the same load in a different manner by modifying or replacing the scripts at the keypad and/or the node controlling the load.
- the functions of the nodes can be defined and/or redefined by the script(s), without having to modify the hardware itself.
- the script(s) may be defined based on various parameters, such as the needs and desires of the building occupant. Although the script(s) may be generic (i.e., applicable to one or more predefined configurations), the script(s) are preferably custom or tailored for each use and is therefore defined once the configuration of a particular building automation system is known. As previously described, the script(s) can preferably also be reconfigured based on the changing needs and/or desires of the building occupants.
- scripts may be defined in any suitable manner. Scripts are computer-readable program code optimized for programmer efficiency (e.g., it is relatively easy to write, flexible, and readily modified). Scripts are preferably independent of the type of processor and/or operating system and are therefore portable to a variety of different environments. Among other advantages, scripts may also comprise predefined, high-level routines, such as string manipulation operators, regular expressions, and associative arrays.
- FIG. 4 is a portion of one embodiment of a script 400 which may be used with the distributed control system of the present invention. It is noted, however, that the scripts are not limited to any particular format and the embodiment shown in FIG. 4 is merely exemplary for purposes of illustrating its use with the present invention.
- each line of script 400 comprises a hexadecimal address 410 , a data type 415 , and a configuration variable 420 .
- lines 440 , 445 of the script 400 are headers which describe a first and second state of a keypad, respectively, and point to script commands.
- Lines 450 and 455 of script 400 describe script commands or command sets that the script headers 440 , 445 point to, respectively.
- scripts may comprise compiled languages and assembly language which can be readily modified to change the functionality of the node 110 without having to modify the hardware itself.
- the script(s) may be modified or replaced. Modifying or replacing the program code is particularly advantageous when one or more nodes 110 are added or removed from the building automation system 100 , or where the user desires a change.
- the script(s) may be modified where the user desires a change.
- the script(s) may be modified where the user desires to change one or more parameters for node 110 (e.g., defining a new key, changing the lighting intensity or slew rate).
- the script(s) may be readily changed to reflect needs and/or desires of the new occupants.
- node 110 may be provided with script(s) 400 at any time, and may be updated and/or modified at any time to change one or more functions of the node 110 and/or fix program “bugs”.
- node 110 may be provided with script(s) 400 during manufacture, during installation, or at any time thereafter.
- the nodes may also be reprogrammed without having to shut down the automation network, or having to shut down(e.g., turn-off, restart, or otherwise take offline) the other nodes in the automation network.
- This may be referred to as “hot reprogramming” or “hot reprogrammability” and can be accomplished by updating firmware (e.g., program code residing at the node 110 which reads the signals and executes the corresponding script(s) 400 ), and/or updating one or more script 400 at the node 110 .
- the bridge 180 receives firmware and/or script 400 updates.
- the bridge 180 may receive updates from a remote site (e.g., via an Internet connection).
- the bridge 180 may receive updates generated by a user on-site and linked to the bridge 180 .
- the bridge 180 determines which node(s) 110 in the automation system is to be updated.
- the bridge 180 may implement a version table identifying each node 110 in the automation network and which firmware version and/or scripts 400 reside at the corresponding nodes 110 .
- the bridge uses the version table to identify node(s) 110 .
- the bridge uses the version table to identify node(s) 110 with an older version of the firmware and/or scripts 400 .
- the user may identify for the bridge 180 one or more of the node(s) 110 that is to be updated.
- the bridge 180 may “wrap” the firmware and/or scripts 400 in one or more CAN packet (or other suitable protocol) for transmission to the node 110 over the automation network.
- the bridge 180 “wraps” the firmware and/or scripts 400 by parsing the code comprising the firmware and/or scripts and entering the parsed data into the data portion of the packet. Additional identifiers for reassembling the firmware and/or scripts 400 at the node 110 may also be provided. For example, identifiers may be provided for the start of the code, the ordering of the code, and the end of the code.
- the bridge 180 addresses in the packet the node(s) that are to receive the update.
- the bridge 180 may then issue the packet to the node(s) 110 over the automation network.
- the node After being received at the node(s) 110 , the node reassembles the firmware and/or scripts 400 and replaces earlier versions at the node(s) 110 .
- the node(s) 110 receiving the updates are take offline during the update. That is, the node(s) 110 receiving the updates may be logically disconnected from the automation network while replacing the firmware and/or scripts 400 so that the previous version can be removed and the node restarted (if necessary) without interruptions from other operations in the automation network.
- the other nodes remain online and are able to send, receive, and respond to communications in the automation network.
- the bridge 180 may implement failure monitoring and recovery operations.
- the node(s) 110 receiving the updates issue at least one acknowledgement (ACK) indicating that each packet (or all of the packets) were received for the update. If the acknowledgement(s) are not received by the bridge 180 within a predetermined time, the bridge 180 may determine that transmission failed and reissue the packets.
- the bridge 180 may test the node(s) 110 to determine whether the update was successful. For example, the bridge 180 may ping the node(s) 110 and in response the nodes(s) 110 respond with version information. If the version information does not match the updated version information, the bridge 180 may determine that the update was unsuccessful and retry the update. If the bridge 180 is unsuccessful at retrying the update (e.g., the node is “hung-up” and requires user intervention to hard-reset the node), the bridge 180 may issue an alert to the user or service provider.
- ACK acknowledgement
- Distributed control system 100 may be operated according to embodiments of the invention, as follows.
- Node 110 may respond to an event by either executing at least one script to perform a function, or issuing a signal 300 to one or more of the other nodes.
- the nodes 110 may in turn perform a function corresponding to the signal 300 .
- a user presses a key at a first node (e.g., 111 )
- the first node 111 may issue a signal 300 associated with the event.
- the signal 300 may be received at a second node (e.g., 112 ), wherein the second node performs one or more functions (e.g., adjust lighting intensity) corresponding to the signal 300 .
- FIG. 5 is a flowchart illustrating exemplary operation in an exemplary distributed control system.
- node 110 may respond to an event 501 , (e.g., a keypad button being pushed, output from a timer or sensor, etc.) by performing a function in operation 510 .
- the node 110 may light an LED on the keypad.
- the node 110 may execute one or more scripts.
- node 110 may generate a signal 300 associated with the event in operation 520 .
- node 110 may generate signal(s) that are representative of input received by the node 110 (e.g., the key(s) a user pressed).
- executing at least one script may generate signal(s) at node 110 .
- the signal(s) 300 may be received by one or more of the other nodes 110 (or by itself, e.g., in a stand-alone embodiment), in operation 530 .
- Each node 110 receiving the signal determines whether it should respond to the signal 300 in operation 540 .
- the signal(s) 300 are issued by broadcasting the signal(s) 300 over the network 130 to each of the other nodes 110 .
- operation 540 may comprise signal filter 262 comparing the Event ID 320 of received signal 300 to events that the node 110 responds to.
- the node 110 responds in operation 550 if the event(s) identified by the Event ID 320 are a type that the node 110 responds to. If the node 110 determines that it should not respond, it does nothing (i.e., the node “ignores” the signal) by ending in operation 555 .
- the signal 300 may be addressed to one or more of the nodes 110 . Accordingly, the signal filter 262 determines whether the node 110 should respond to the signal 300 based on the Address 310 of the signal 300 . It is noted that in any embodiment, more than one node 110 may respond to the signal 300 .
- the node 110 responds to the signal 300 in operation 550 by executing at least one script corresponding to the signal 300 .
- executing the script(s) drives a load 560 .
- the node 110 may comprise lighting controls (e.g., the load). Accordingly, executing the script(s) controls lighting on a lighting circuit.
- a keypad is a scripted node 250
- a lighting control circuit is an unscripted node 200 .
- the keypad responds to a user pressing a key by executing the script 400 ( FIG. 4 ), as follows.
- the script 400 FIG. 4
- the first command is defined by lines 450.
- program code for executing the script 400 may call program code for generating a signal 300 and issuing the signal 300 over the network.
- Signal 300 may comprise control instructions based on the executed script 400 .
- Control instructions are preferably recognizable by the node 110 receiving the signal 300 to activate the lighting circuit as described by the script.
- script 400 may be readily modified for use by a scripted lighting control.
- the scripted lighting control may receive a signal 300 (e.g., from a keypad).
- Signal filter 262 at the scripted lighting control may determine whether the scripted lighting control should respond to the signal 300 (e.g., if the Event ID corresponds to functions in headers 440 , 445 of script 400 ). If the scripted lighting control should respond to the signal 300 , distributed controller 211 executes commands defined by lines 450, 455 of script 400 . Executing the script may call program code for activating the lights according to the executed script 400 .
- the lighting control in the above example may be a scripted node 250 .
- the distributed control system 100 of the present invention is also well-suited for performing more elaborate functions, now know or that may be later developed, as will be readily appreciated by one skilled in the art after having become familiar with the teachings of the present invention.
- One such embodiment may comprise an unscripted node 200 responding to an event and a scripted node 250 receiving a signal 300 corresponding to the event from the unscripted node 200 .
- the unscripted node 200 may respond to the event by issuing a signal 300 that identifies the event (e.g., “keypad button one pressed ”).
- the scripted node 250 receives the signal 300 identifying the event and executes at least one script provided at the scripted node 250 that corresponds to the signal 300 to perform one or more functions corresponding to the signal 300 (e.g., adjust lighting intensity).
- a scripted node 250 may respond to the event, and an unscripted node 200 may receive the signal 300 .
- the scripted node 250 may respond to the event by executing script(s) provided to generate a signal 300 .
- the signal 300 comprises a control instruction.
- the unscripted node receives the signal 300 and performs one or more functions defined by the control instruction.
- each of the nodes may be scripted nodes 250 .
- one or more of the scripted nodes 250 may respond to an event by executing script(s).
- the first node may execute script(s) to activate an LED light next to the key that ways pressed, and the scripted node 250 may also issue a signal 300 .
- the one or more of the other scripted nodes 250 may receive the signal 300 and execute script(s) corresponding to the signal 300 to perform one or more functions (e.g., adjust lighting intensity) corresponding to the signal 300 .
- one or more of the nodes 110 may be “stand-alone” nodes.
- the stand-alone node responds to the event by executing script(s) provided at the stand-alone node to perform one or more functions without issuing a signal to the other nodes 110 .
- a scripted node 250 may also function as an unscripted node 200 . Accordingly, the distributed control system 100 can be configured with different types of nodes 110 or operating in different modes to operate according to the various embodiments described herein.
- distributed control system 100 may also comprise any combination of these embodiments. Further combinations will also be appreciated by the skilled in the art after having become familiar with the teachings of the present invention.
- the distributed control system 100 may also be operated to provide acknowledgements.
- the executed script(s) may generate a command signal and issue it to another of the nodes 110 .
- a lighting control node may issue a command signal to a keypad node instructing the keypad node to turn on an LED light or display a message on an LCD display at the keypad indicating to the user that the lighting is turned on.
- the acknowledgement field of signal 300 may comprise an acknowledgement or “ACK” message.
- the acknowledgement field may be a negative acknowledged or “NAK” message when the received signal(s) cannot be read or are otherwise unusable.
- Other status signals may also be issued from the node 110 to another to indicate to the user and/or other devices the status of the node 110 issuing the status signal.
Abstract
Description
- This application claims priority as a continuation-in-part of co-owned U.S. patent application Ser. No. 10/422,525 for “Distributed Control Systems and Methods ” of Hesse, et al., filed Apr. 24, 2003, hereby incorporated by reference in its entirety as though fully set forth herein.
- 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.
- Building automation systems may be implemented using extensive computer networks. Computer networks are known in which a server computer issues a series of commands over an Ethernet network to an output device. The commands are complex data structures requiring the server computer to establish an elaborate communications protocol between the server computer and the output device, followed by the server transmitting multiple data packets containing the commands.
- Transmitting these commands consumes significant bandwidth on the network, especially when more than one command is issued to the same or multiple output devices at the same time or within a close timeframe. Network performance decreases, resulting in slow transmission speeds and sometimes even recognizable delays in the response time. Transmitting commands also increases the potential for data corruption resulting in failed operations. In addition, when the server computer fails, all of the devices on the network are “down.”
-
FIG. 1 is a high-level schematic diagram of an exemplary distributed control system. -
FIG. 2 (a) and (b) are high-level schematic diagrams of an exemplary node that may be implemented in a distributed control system. -
FIG. 3 is an illustration of an exemplary signal that may be implemented in a distributed control system. -
FIG. 4 is a portion of one embodiment of a script which may be used with the distributed control system of the present invention. -
FIG. 5 is a flowchart illustrating exemplary operations in an exemplary distributed control system. - Distributed control systems are disclosed as it may be used in a building automation environment, although other uses are also contemplated as being within the scope of the invention (e.g., manufacturing, water supply monitoring, and a variety of other environments). Briefly, distributed control system may be used to automate various functions (e.g., control one or more loads), such as, but not limited to, lighting, climate control, audio/visual output, and various monitoring systems (e.g., security), to name only a few examples.
- In an exemplary embodiment, the distributed control systems may include a number of automation devices or “nodes” operatively associated with one another over one or more automation network(s). The nodes may comprise any of a wide variety of control and/or controlled devices now known or later developed. In a building automation environment, for example, the nodes may be devices that respond to events (e.g., keypads, temperature sensors, timers, water-level sensors), devices that control various functions (e.g., lighting controls, motor controls), or a combination thereof.
- In exemplary embodiments, individual nodes may be programmed and reprogrammed without affecting the other nodes on the network, without interfering with the operation of other nodes or the building automation network, and without having to shut off or restart other nodes or the building automation network. Accordingly, the distributed control system may be readily modified for different and/or additional devices and functions at any time, either locally or directly at the node, or from a remote location by the user (e.g., a homeowner or service provider). The distributed control system may also be readily modified at any time, even after the initial installation, allowing automated functions to be readily tailored for the user's preferences.
- Exemplary System
-
FIG. 1 is a high-level schematic diagram of any exemplary distributed control system. Thedistributed control system 100 may comprise a number of automation devices or “nodes” 110. In the embodiment shown inFIG. 1 , thenodes 110 are operatively associated with one another over one or more networks 130 (cumulatively referred to as the “automation network”), although it is understood that a “stand-alone” node may also be implemented. -
Nodes 110 may be linked to one another over various types of networks. According to one embodiment,nodes 110 are linked using a controller area network (CAN) bus. Such an embodiment ofbuilding automation system 100 is described in more detail in co-pending, co-owned U.S. patent application Ser. No. 10/382,979, entitled “BUILDING AUTOMATION SYSTEM AND METHOD” of Hesse, et al., filed on Mar. 5, 2003, which is hereby incorporated herein by reference for all that it discloses. - Briefly, the CAN bus comprises 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 can be extended to about 10,000 meters at transmission speeds of about 5 kilobits per second (kbits/s) It is also a robust bus and can be operated in noisy electrical environments while maintaining the integrity of the data.
- The CAN specification is currently available as version 1.0 and 2.0 and is published by the International Standards Organization (ISO) as standards 11898 (high-speed) and 11519 (low-speed). The CAN specification defines communication services and protocols for the CAN bus, in particular, the physical layer and the data link layer for communication over the CAN bus. Bus arbitration and error management is also described. Of course the invention is not limited to any particular version and it is intended that other specification for the CAN bus now know or later developed are also contemplated as being within the scope of the invention.
- It is understood, however, that the present invention is not limited to use with the CAN bus and other types and/or configurations of networks are also contemplated as being within the scope of the invention. Other networks may also comprise an Ethernet or a wireless network (e.g., radio frequency (RF), BLUETOOTH™, ZIGBEE™), to name only a few. In addition, the
network 130 may comprise more than one network (e.g., 131), or subnets as they are sometimes referred to. In another embodiment, for example, the network may comprise a plurality of CAN bus subnets, each linked to one another by an Ethernet network. Bridging apparatus orbridge 180 may be provided to link the networks to one another. - It is also understood that
nodes 110 may be operatively associated with thenetwork 130 in any suitable manner, including by permanent, removable, or remote link. By way of example,nodes 110 may be permanently linked to thenetwork 130 by a hard-wire connection. Alternatively,nodes 110 may be removably lined to the network by a “plug-type” connection.Nodes 110 may also be remotely linked to the network, for example via an RF link. Suitable interfaces may be provides fornodes 110 for issuing and receiving signals over thenetwork 130. Such interfaces can be readily provided by one skilled in the art after having become familiar with the teachings of the present invention. - Before continuing, it should be noted that the
distributed control system 100 may be provided with an optional link 160 (e.g., linked to thenetwork 130 via an interface). In one embodiment,link 160 may comprise an external link from another network such as the Internet through an Internet service provider (ISP). In another embodiment,link 160 may comprise a link from another device on the same network (e.g.,bridge 180 or server computer).Link 160 may be used to import/export thescripts 400 to thenodes 110 during installation or to configure or reconfigure one or more of thenodes 110 at a later time. - Of course, it is understood that the
link 160 is not limited to an ISP link. In other embodiments, thelink 160 may be via a local area network (LAN), a wide area network (WAN), an Intranet, a telephony link, a digital subscriber line (DSL), T-1 connection, cellular line, satellite link, etc. In addition,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,link 160 may comprise a temporary connection for use by a service technician or the user. For example, thelink 160 may comprise a link for connecting a laptop computer to thenetwork 130. -
Nodes 110 may be any device or combination of devices generally configured to respond to an event.Nodes 110 may comprise, but are not limited to, keypads, knobs, sliders, touch-screens, graphical user interfaces (GUI), control systems (e.g., lighting control circuits, HVAC systems, security systems), personal computers (PC) and PC accessories, and other devices that are now known or later developed. In addition,nodes 110 may be operatively associated with, and receive input from external devices (e.g., clocks, water level sensors, temperature sensors, light sensors). - FIGS. 2(a) and (b) are high-level schematic diagrams of an exemplary node that may be implemented in a distributed control system. FIG 2(a) shows one embodiment of an “unscripted” node 200 (e.g., a keypad).
Unscripted node 200 may comprise acontroller 210 operatively associated with thenetwork 130 vianetwork interface 220.Controller 210 is preferably configured to respond to an event (e.g., receive input 230) by generating asignal 300 associated with the event (e.g., identifies the event). Optionally, thesignal 300 may also contain a field identifying an address of the source of the event.Controller 210 may be provided with computer-readable program code (e.g., firmware on computer readable storage 270). In one embodiment, computer-readable program code may comprise program code for processing anevent 212 and program code for generating and/or issuing asignal 214. Accordingly, thecontroller 210 may respond to an event (e.g., by receiving input and generating a signal corresponding to the event).Controller 210 may also generateoutput 240. For example,output 240 may comprise lighting and LED light (e.g., indicating a pressed key on a keypad, a status light, etc.). - It is noted that controllers such as provided for
unscripted node 200 that can perform one or more predetermined functions are well-known in the electronics art and may comprise, by way of example, one or more programmable logic devices (PLDs) such as a field programmable gate array (FPGA), application-specific integrated circuit (ASIC), or microprocessor, to name only a few. It is also noted that network interfaces 220 are also readily available and the selection of a suitable network interface will depend to some extent of the type ofnetwork 130. - It is also well within the ability of one skilled in the art to provide computer-
readable storage 270 for use with the present invention. Exemplary embodiments of computer-readable storage include, but are not limited to various types of programmable memory, read-only memory (ROM), random access memory (RAM), flash memory, magnetic storage, a combination thereof, etc. It is noted that the memory can also be an integral part of the controller. Further explanation of computer-readable storage 270 is not necessary for a complete understanding of the invention, and therefore is not described in further detail herein. -
Unscripted node 200 is preferably used with a “scripted” node.Scripted node 250 is shown according to one embodiment inFIG. 2 (b) and may comprise a distributedcontroller 211 is also preferably operatively associated with computer-readable storage 271. Computer-readable storage 271 may be accessed before, during, or after installation (e.g., via link 160) to provide at least one script for use with thescripted node 250. - Distributed
controller 211 is preferably also configured to respond to an event. For example, distributedcontroller 211 may respond to signal 300 or other input received overnetwork 130. Distributedcontroller 211 may also generate output (e.g., issue a signal over network 130). - Distributed
controller 211 preferably comprises computer-readable program code (e.g., residing on computer-readable storage 270) for responding to signal 300 or other input. In one embodiment, distributedcontroller 211 may comprise asignal filter 262, program code for executingscripts 264, and program code for controlling one or more loads 266. -
Signal filter 262 may be provided to determine whether asignal 300 issued over thenetwork 130 is intended forscripted node 250. For example,signal filter 262 may compare the event associated with the signal to a one or more types of events that thescripted node 250 responds to (e.g., as defined by the script header). - If the
signal 300 is intended forscripted node 250, program code for executing the script may read thesignal 300 and execute at least one script corresponding to the signal. Embodiments of scripts are described in more detail below. For now, it is enough to understand that the executed script(s) may perform a function, and preferably drives a load (e.g., turn on a lighting circuit). - An
unscripted node 200 may receive input and issue signals associated with the input to another node.Unscripted node 200 may receive signals from other nodes and issue a response or action such as, e.g., sending a signal indicating an LED state, or activating an LED. Likewise, ascripted node 250 may receive signals from other nodes and perform one or more functions (e.g., driving a load) corresponding to the signals as instructed by the executed script(s). However, it is understood that thenodes 110 are not limited only to these operations. For example,nodes 110 can be configured to receive input, issue signals and/or perform one or more functions (e.g., driving a load). Such a node, although not shown, may be readily provided by combining components from both embodiments shown in FIGS. 2(a) and (b) and described above. - It is also noted that
nodes 110 may also be configured with other sources to receive input and/or send output, and are not limited to I/O operations only withother nodes 110. For example,nodes 110 may receive input directly from sensors or timers operatively associated with thenodes 110, and send output to displays, data logs, etc. - As will be readily appreciated by those skilled in the art,
nodes 110 may be provided with various ancillary devices, for example, power supplies, electronic controls, input/output (I/O) devices, etc. Such ancillary devices are well-understood and therefore are not shown or described herein as further description is not needed for a full understanding of, or to practice the invention. - In operation, one or more of the
nodes 110 respond to various events. The scope of the present invention is not limited to any particular type of event. By way of example, events may include, but are not limited to a user pressing a key on a keypad, a clock indicating the time, a light sensor indicating the level of outdoor light, a water level sensor indicating the water level in a body of water, a flow control sensor indicating the flow of water, to name only a few. - As briefly described above, an
unscripted node 200 may respond to an event by issuing a signal 300 (e.g., over network 130) to ascripted node 250. For purposes of illustration, an unscripted keypad may issue one or more signals in response to the user pressing a key (or sequence of keys). However, it is understood that in other embodiments, ascripted node 250 may issue asignal 300 to anunscripted node 200, or ascripted node 250 may issue asignal 300 to anotherscripted node 250. -
FIG. 3 is an illustration of an exemplary signal that may be implemented in a distributed control system.Signal 300 may comprise one or more fields 310-330. Preferably, at least one of the fields comprises anEvent ID field 320 which comprises an event identifier.Signal 300 may also comprise one or fields. For example, signal 300 may comprise anaddress field 310 with the network address of one or more of thenodes 110 so that thesignal 300 can be delivered to one or more addressed nodes in thenetwork 130. - In one embodiment, the
node 110generating signal 300 may issue redundant signals 300. Aredundant signal 300 preferably is a copy of thesignal 300, which may be issued over thenetwork 130 sequentially, or at a later time (e.g., if the first signal is not received or is corrupted). Accordingly, if one of thesignals 300 is misdirected, corrupted or otherwise unusable upon receipt by another device, the redundant signal is issued to thenode 110.Redundant signal 300 may be issued automatically (e.g., following a time-out) or at the request of one or more of thenodes 110. - Other embodiments are also contemplated as being within the scope of the invention. As briefly mentioned above, signals 300 may be addressed to specific devices or categories of devices. Alternatively, signal 300 may be a global signal that is issued to all of the
nodes 110 on thenetwork 130 or one ormore subnets 131. For example, signal 300 may be addressed to groups ofnodes 110, such as all the outdoor lighting, so that all of the functions associated with thosenodes 110 can be controlled without the need for issuing separate signals to eachnode 110. - the node(s) receiving
signal 300 may respond by executing at least one script to perform any one or more of a variety of functions. Script(s) 400 for performing various functions may be provided on the computer-readable storage 271 of ascripted node 250 and can be executed at thescripted node 250 by the distributedcontroller 211. In addition, other messages can be received by thenode 110 and processed locally without the use of a script. - Executing the at least one script performs one or more functions, and preferably drives a load. For example, the executed script(s) may activate or deactivate a load, and preferably even control one or more parameters of the load (e.g., slew rate or intensity in the case of lighting). If the
node 110 is a triac board, for example, the executed program code may turn on lighting (e.g., the load) to 50 % intensity by slewing over 30 seconds. - It will be readily appreciated upon understanding the invention that the manner in which the load is controlled and/or the type of load that is controlled can be readily modified or altogether changed by modifying or replacing the script(s). By way of example, one or more of the buttons on a keypad can be defined to control one or more loads according to various parameters, and later the same buttons can be defined to control one or more different loads, and/or to control the same load in a different manner by modifying or replacing the scripts at the keypad and/or the node controlling the load. The functions of the nodes can be defined and/or redefined by the script(s), without having to modify the hardware itself.
- The script(s) may be defined based on various parameters, such as the needs and desires of the building occupant. Although the script(s) may be generic (i.e., applicable to one or more predefined configurations), the script(s) are preferably custom or tailored for each use and is therefore defined once the configuration of a particular building automation system is known. As previously described, the script(s) can preferably also be reconfigured based on the changing needs and/or desires of the building occupants.
- It is understood that the script(s) may be defined in any suitable manner. Scripts are computer-readable program code optimized for programmer efficiency (e.g., it is relatively easy to write, flexible, and readily modified). Scripts are preferably independent of the type of processor and/or operating system and are therefore portable to a variety of different environments. Among other advantages, scripts may also comprise predefined, high-level routines, such as string manipulation operators, regular expressions, and associative arrays.
-
FIG. 4 is a portion of one embodiment of ascript 400 which may be used with the distributed control system of the present invention. It is noted, however, that the scripts are not limited to any particular format and the embodiment shown inFIG. 4 is merely exemplary for purposes of illustrating its use with the present invention. - The
script 400 shown inFIG. 4 may reside at one or more of thescripted nodes 250. According to this embodiment, each line ofscript 400 comprises a hexadecimal address 410, a data type 415, and aconfiguration variable 420. In this embodiment,lines 440, 445 of thescript 400 are headers which describe a first and second state of a keypad, respectively, and point to script commands.Lines script 400 describe script commands or command sets that thescript headers 440, 445 point to, respectively. - It is understood that other exemplary embodiments of scripts may comprise compiled languages and assembly language which can be readily modified to change the functionality of the
node 110 without having to modify the hardware itself. - In exemplary embodiments, the script(s) may be modified or replaced. Modifying or replacing the program code is particularly advantageous when one or
more nodes 110 are added or removed from thebuilding automation system 100, or where the user desires a change. For example, the script(s) may be modified where the user desires a change. For example, the script(s) may be modified where the user desires to change one or more parameters for node 110 (e.g., defining a new key, changing the lighting intensity or slew rate). For example, when the building changes occupancy, the script(s) may be readily changed to reflect needs and/or desires of the new occupants. - It is understood that
node 110 may be provided with script(s) 400 at any time, and may be updated and/or modified at any time to change one or more functions of thenode 110 and/or fix program “bugs”. For example,node 110 may be provided with script(s) 400 during manufacture, during installation, or at any time thereafter. - The nodes may also be reprogrammed without having to shut down the automation network, or having to shut down(e.g., turn-off, restart, or otherwise take offline) the other nodes in the automation network. This may be referred to as “hot reprogramming” or “hot reprogrammability” and can be accomplished by updating firmware (e.g., program code residing at the
node 110 which reads the signals and executes the corresponding script(s) 400), and/or updating one ormore script 400 at thenode 110. - In an exemplary embodiment, the bridge 180 (or other computer system) receives firmware and/or
script 400 updates. For example, thebridge 180 may receive updates from a remote site (e.g., via an Internet connection). Or for example, thebridge 180 may receive updates generated by a user on-site and linked to thebridge 180. Thebridge 180 determines which node(s) 110 in the automation system is to be updated. For example, thebridge 180 may implement a version table identifying eachnode 110 in the automation network and which firmware version and/orscripts 400 reside at the correspondingnodes 110. When an update is received, the bridge uses the version table to identify node(s) 110. When an update is received, the bridge uses the version table to identify node(s) 110 with an older version of the firmware and/orscripts 400. Alternatively, the user may identify for thebridge 180 one or more of the node(s) 110 that is to be updated. - After identifying the node(s) 110 to be updated, the
bridge 180 may “wrap” the firmware and/orscripts 400 in one or more CAN packet (or other suitable protocol) for transmission to thenode 110 over the automation network. Thebridge 180 “wraps” the firmware and/orscripts 400 by parsing the code comprising the firmware and/or scripts and entering the parsed data into the data portion of the packet. Additional identifiers for reassembling the firmware and/orscripts 400 at thenode 110 may also be provided. For example, identifiers may be provided for the start of the code, the ordering of the code, and the end of the code. In addition, thebridge 180 addresses in the packet the node(s) that are to receive the update. - The
bridge 180 may then issue the packet to the node(s) 110 over the automation network. After being received at the node(s) 110, the node reassembles the firmware and/orscripts 400 and replaces earlier versions at the node(s) 110. It is noted that only the node(s) 110 receiving the updates are take offline during the update. That is, the node(s) 110 receiving the updates may be logically disconnected from the automation network while replacing the firmware and/orscripts 400 so that the previous version can be removed and the node restarted (if necessary) without interruptions from other operations in the automation network. During this process, however, the other nodes remain online and are able to send, receive, and respond to communications in the automation network. - Optionally, the
bridge 180 may implement failure monitoring and recovery operations. In an exemplary embodiment, the node(s) 110 receiving the updates issue at least one acknowledgement (ACK) indicating that each packet (or all of the packets) were received for the update. If the acknowledgement(s) are not received by thebridge 180 within a predetermined time, thebridge 180 may determine that transmission failed and reissue the packets. In another exemplary embodiment, thebridge 180 may test the node(s) 110 to determine whether the update was successful. For example, thebridge 180 may ping the node(s) 110 and in response the nodes(s) 110 respond with version information. If the version information does not match the updated version information, thebridge 180 may determine that the update was unsuccessful and retry the update. If thebridge 180 is unsuccessful at retrying the update (e.g., the node is “hung-up” and requires user intervention to hard-reset the node), thebridge 180 may issue an alert to the user or service provider. - Exemplary Operations
- Distributed
control system 100 may be operated according to embodiments of the invention, as follows.Node 110 may respond to an event by either executing at least one script to perform a function, or issuing asignal 300 to one or more of the other nodes. Thenodes 110 may in turn perform a function corresponding to thesignal 300. By way of example, when a user presses a key at a first node (e.g., 111), thefirst node 111 may issue asignal 300 associated with the event. Thesignal 300 may be received at a second node (e.g., 112), wherein the second node performs one or more functions (e.g., adjust lighting intensity) corresponding to thesignal 300. -
FIG. 5 is a flowchart illustrating exemplary operation in an exemplary distributed control system. Inoperation 500,node 110 may respond to an event 501, (e.g., a keypad button being pushed, output from a timer or sensor, etc.) by performing a function inoperation 510. For example, thenode 110 may light an LED on the keypad. As another example, thenode 110 may execute one or more scripts. Alternatively, or in addition to performing a function,node 110 may generate asignal 300 associated with the event inoperation 520. By way of example,node 110 may generate signal(s) that are representative of input received by the node 110 (e.g., the key(s) a user pressed). In another example, executing at least one script (e.g., in operation 510) may generate signal(s) atnode 110. In any event, the signal(s) 300 may be received by one or more of the other nodes 110 (or by itself, e.g., in a stand-alone embodiment), inoperation 530. Eachnode 110 receiving the signal determines whether it should respond to thesignal 300 in operation 540. - According to one embodiment, the signal(s) 300 are issued by broadcasting the signal(s) 300 over the
network 130 to each of theother nodes 110. In this embodiment, operation 540 may comprisesignal filter 262 comparing theEvent ID 320 of receivedsignal 300 to events that thenode 110 responds to. Thenode 110 responds inoperation 550 if the event(s) identified by theEvent ID 320 are a type that thenode 110 responds to. If thenode 110 determines that it should not respond, it does nothing (i.e., the node “ignores” the signal) by ending in operation 555. - In other embodiments, the
signal 300 may be addressed to one or more of thenodes 110. Accordingly, thesignal filter 262 determines whether thenode 110 should respond to thesignal 300 based on theAddress 310 of thesignal 300. It is noted that in any embodiment, more than onenode 110 may respond to thesignal 300. - The
node 110 responds to thesignal 300 inoperation 550 by executing at least one script corresponding to thesignal 300. In exemplary embodiments, executing the script(s) drives a load 560. In one example, thenode 110 may comprise lighting controls (e.g., the load). Accordingly, executing the script(s) controls lighting on a lighting circuit. - Having generally described operation of the distributed
control system 100 according to embodiments of the invention, the following example is provided to be illustrative of operation of the distributedcontrol system 100 in one embodiment of the invention. In this example, a keypad is ascripted node 250, and a lighting control circuit is anunscripted node 200. With reference again to FIGS. 2(a) and (b), andFIG. 4 , the keypad responds to a user pressing a key by executing the script 400 (FIG. 4 ), as follows. In this example, we will consider two states of one of the keys (i.e., State 01 and State 02). - In the first state (e.g., off), the keypad button is depressed and has a state cButtonState=0×00(line 0000000e). No commands are logically associated with the first state in this example (line 0000000f). Accordingly, nothing happens.
- In the second state (e.g., on), keypad button is released and has a state cButtonState=0×001(line 00000017). Two commands are logically associated with the second state in this example (line 00000018). The first command is defined by
lines 450. In this example,lines 450 define a load wType=0×0002 (e.g., a lighting control), and corresponding parameters, such as time delay (line 00000021), slew rate (00000022), and so forth. - The second command is defined by
lines 455. In this example,lines 455 define a load wType=0×001 (e.g., and LED light next to the key that was pressed), and corresponding parameters such as activating the LED (line 0000002b). - Accordingly, program code for executing the
script 400 may call program code for generating asignal 300 and issuing thesignal 300 over the network.Signal 300 may comprise control instructions based on the executedscript 400. Control instructions are preferably recognizable by thenode 110 receiving thesignal 300 to activate the lighting circuit as described by the script. - It is readily apparent from an understanding of the above example that
script 400 may be readily modified for use by a scripted lighting control. According to such an embodiment, the scripted lighting control may receive a signal 300 (e.g., from a keypad).Signal filter 262 at the scripted lighting control may determine whether the scripted lighting control should respond to the signal 300 (e.g., if the Event ID corresponds to functions inheaders 440, 445 of script 400). If the scripted lighting control should respond to thesignal 300, distributedcontroller 211 executes commands defined bylines script 400. Executing the script may call program code for activating the lights according to the executedscript 400. - Of course it is understood that the above example is merely illustrative of one embodiment of the invention, and the scope of the invention is not intended to be limited to the above example. For example, the lighting control in the above example may be a
scripted node 250. The distributedcontrol system 100 of the present invention is also well-suited for performing more elaborate functions, now know or that may be later developed, as will be readily appreciated by one skilled in the art after having become familiar with the teachings of the present invention. - The following provides a brief overview of operation of the distributed
control system 100 according to other embodiments contemplated as being within the scope of the invention. One such embodiment may comprise anunscripted node 200 responding to an event and ascripted node 250 receiving asignal 300 corresponding to the event from theunscripted node 200. In operation, theunscripted node 200 may respond to the event by issuing asignal 300 that identifies the event (e.g., “keypad button one pressed ”). Thescripted node 250 receives thesignal 300 identifying the event and executes at least one script provided at thescripted node 250 that corresponds to thesignal 300 to perform one or more functions corresponding to the signal 300 (e.g., adjust lighting intensity). - In another embodiment, a
scripted node 250 may respond to the event, and anunscripted node 200 may receive thesignal 300. In operation, thescripted node 250 may respond to the event by executing script(s) provided to generate asignal 300. Thesignal 300 comprises a control instruction. The unscripted node receives thesignal 300 and performs one or more functions defined by the control instruction. - In yet another embodiment, each of the nodes may be scripted
nodes 250. In operation, one or more of thescripted nodes 250 may respond to an event by executing script(s). For example, the first node may execute script(s) to activate an LED light next to the key that ways pressed, and thescripted node 250 may also issue asignal 300. The one or more of the otherscripted nodes 250 may receive thesignal 300 and execute script(s) corresponding to thesignal 300 to perform one or more functions (e.g., adjust lighting intensity) corresponding to thesignal 300. - In still another embodiment, one or more of the
nodes 110 may be “stand-alone” nodes. In operation, the stand-alone node responds to the event by executing script(s) provided at the stand-alone node to perform one or more functions without issuing a signal to theother nodes 110. - In yet other embodiments, a
scripted node 250 may also function as anunscripted node 200. Accordingly, the distributedcontrol system 100 can be configured with different types ofnodes 110 or operating in different modes to operate according to the various embodiments described herein. - Of course distributed
control system 100 may also comprise any combination of these embodiments. Further combinations will also be appreciated by the skilled in the art after having become familiar with the teachings of the present invention. - distributed
control system 100 may also be operated to provide acknowledgements. In one exemplary embodiment, the executed script(s) may generate a command signal and issue it to another of thenodes 110. For example, a lighting control node may issue a command signal to a keypad node instructing the keypad node to turn on an LED light or display a message on an LCD display at the keypad indicating to the user that the lighting is turned on. - In another exemplary embodiment, the acknowledgement field of
signal 300 may comprise an acknowledgement or “ACK” message. Likewise, the acknowledgement field may be a negative acknowledged or “NAK” message when the received signal(s) cannot be read or are otherwise unusable. Other status signals may also be issued from thenode 110 to another to indicate to the user and/or other devices the status of thenode 110 issuing the status signal. - The operations shown and described herein are provided to illustrate exemplary embodiments for reprogramming nodes in an automation environment. It is noted that the operations are not limited to the ordering shown. In addition, other operation, not shown, may also be implemented.
- 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 (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/462,749 US20060271204A1 (en) | 2003-04-24 | 2006-08-07 | Hot Reprogrammability of Building Automation Devices |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/422,525 US7089066B2 (en) | 2003-04-24 | 2003-04-24 | Distributed control systems and methods |
US11/462,749 US20060271204A1 (en) | 2003-04-24 | 2006-08-07 | Hot Reprogrammability of Building Automation Devices |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/422,525 Continuation-In-Part US7089066B2 (en) | 2003-04-24 | 2003-04-24 | Distributed control systems and methods |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060271204A1 true US20060271204A1 (en) | 2006-11-30 |
Family
ID=33298912
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/422,525 Expired - Lifetime US7089066B2 (en) | 2003-04-24 | 2003-04-24 | Distributed control systems and methods |
US11/462,749 Abandoned US20060271204A1 (en) | 2003-04-24 | 2006-08-07 | Hot Reprogrammability of Building Automation Devices |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/422,525 Expired - Lifetime US7089066B2 (en) | 2003-04-24 | 2003-04-24 | Distributed control systems and methods |
Country Status (2)
Country | Link |
---|---|
US (2) | US7089066B2 (en) |
WO (1) | WO2004097557A2 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080126778A1 (en) * | 2006-08-30 | 2008-05-29 | Bishop Bradley W | System and method for applying a destructive firmware update in a non-destructive manner |
US20110245938A1 (en) * | 2010-04-01 | 2011-10-06 | ESI Ventures, LLC | Modular centralized lighting control system for buildings |
US20110270417A1 (en) * | 2010-04-28 | 2011-11-03 | Kabushiki Kaisha Toshiba | Control system and control method |
US20120011488A1 (en) * | 2009-05-22 | 2012-01-12 | Noriaki Suzuki | Script description separation reconstructing device, script description separation reconstructing method, and non-transitory computer readable medium storing script description separation reconstructing program |
US20130304259A1 (en) * | 2012-05-09 | 2013-11-14 | Honeywell International Inc. | Airflow and water balancing |
WO2014182623A1 (en) * | 2013-05-09 | 2014-11-13 | Siemens Industry, Inc. | Interface for adjustment of portions of a building automation system |
WO2018034575A1 (en) * | 2016-08-16 | 2018-02-22 | Darc Technologies Limited | A power line carrier transceiver, distributed automation system, and methods of operation |
Families Citing this family (62)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7835372B2 (en) * | 2002-05-13 | 2010-11-16 | Weilin Wang | System and method for transparent wireless bridging of communication channel segments |
US7941149B2 (en) | 2002-05-13 | 2011-05-10 | Misonimo Chi Acquistion L.L.C. | Multi-hop ultra wide band wireless network communication |
US8780770B2 (en) | 2002-05-13 | 2014-07-15 | Misonimo Chi Acquisition L.L.C. | Systems and methods for voice and video communication over a wireless network |
US7957356B2 (en) | 2002-05-13 | 2011-06-07 | Misomino Chi Acquisitions L.L.C. | Scalable media access control for multi-hop high bandwidth communications |
US7433740B2 (en) * | 2003-03-05 | 2008-10-07 | Colorado Vnet, Llc | CAN communication for building automation systems |
US20040176877A1 (en) * | 2003-03-05 | 2004-09-09 | Scott Hesse | Building automation system and method |
US20040218591A1 (en) * | 2003-04-29 | 2004-11-04 | Craig Ogawa | Bridge apparatus and methods of operation |
JP4503954B2 (en) * | 2003-08-21 | 2010-07-14 | 株式会社日立ハイテクインスツルメンツ | Substrate positioning device and substrate positioning method |
US7114554B2 (en) | 2003-12-01 | 2006-10-03 | Honeywell International Inc. | Controller interface with multiple day programming |
US7774474B2 (en) * | 2003-12-23 | 2010-08-10 | Nortel Networks Limited | Communication of control and data path state for networks |
US8195744B2 (en) | 2004-07-09 | 2012-06-05 | Orb Networks, Inc. | File sharing system for use with a network |
US7937484B2 (en) | 2004-07-09 | 2011-05-03 | Orb Networks, Inc. | System and method for remotely controlling network resources |
US8819140B2 (en) | 2004-07-09 | 2014-08-26 | Qualcomm Incorporated | System and method for enabling the establishment and use of a personal network |
US9077766B2 (en) | 2004-07-09 | 2015-07-07 | Qualcomm Incorporated | System and method for combining memory resources for use on a personal network |
US8787164B2 (en) | 2004-07-09 | 2014-07-22 | Qualcomm Incorporated | Media delivery system and method for transporting media to desired target devices |
US8738693B2 (en) | 2004-07-09 | 2014-05-27 | Qualcomm Incorporated | System and method for managing distribution of media files |
US7584897B2 (en) | 2005-03-31 | 2009-09-08 | Honeywell International Inc. | Controller system user interface |
US8001219B2 (en) * | 2006-03-16 | 2011-08-16 | Exceptional Innovation, Llc | User control interface for convergence and automation system |
US8155142B2 (en) * | 2006-03-16 | 2012-04-10 | Exceptional Innovation Llc | Network based digital access point device |
US7966083B2 (en) | 2006-03-16 | 2011-06-21 | Exceptional Innovation Llc | Automation control system having device scripting |
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 |
WO2007124453A2 (en) | 2006-04-20 | 2007-11-01 | Exceptional Innovation Llc | Touch screen for convergence and automation system |
JP2007298056A (en) * | 2006-04-27 | 2007-11-15 | Tsubakimoto Chain Co | Anticorrosive roller chain |
US7667968B2 (en) | 2006-05-19 | 2010-02-23 | Exceptional Innovation, Llc | Air-cooling system configuration for touch screen |
US8402150B1 (en) | 2006-07-31 | 2013-03-19 | Automated Irrigation Controls, LLC | Manipulation of LonWorks® protocol for RF communications |
US8175613B2 (en) | 2006-08-04 | 2012-05-08 | Misonimo Chi Acquisitions L.L.C. | Systems and methods for determining location of devices within a wireless network |
US8973072B2 (en) | 2006-10-19 | 2015-03-03 | Qualcomm Connected Experiences, Inc. | System and method for programmatic link generation with media delivery |
US7962130B2 (en) | 2006-11-09 | 2011-06-14 | Exceptional Innovation | Portable device for convergence and automation solution |
JP4861484B2 (en) | 2006-12-07 | 2012-01-25 | ミソニモ チ アクイジションズ エル.エル.シー. | System and method for assigning time slots and channels |
DE102007022855A1 (en) * | 2007-05-15 | 2008-11-20 | Robert Bosch Gmbh | Method for cooling components of a motor vehicle |
US8116327B2 (en) * | 2007-07-30 | 2012-02-14 | Motorola Solutions, Inc. | Communications network and management arbitrator |
US20090198458A1 (en) * | 2008-01-29 | 2009-08-06 | Mcdermid John | Water measurement auto-networks |
US20090206983A1 (en) * | 2008-02-19 | 2009-08-20 | Lutron Electronics Co., Inc. | Communication System for a Radio-Frequency Load Control System |
US9013059B2 (en) | 2009-07-30 | 2015-04-21 | Lutron Electronics Co., Inc. | Load control system having an energy savings mode |
US8417388B2 (en) | 2009-07-30 | 2013-04-09 | Lutron Electronics Co., Inc. | Load control system having an energy savings mode |
US8666555B2 (en) * | 2009-07-30 | 2014-03-04 | Lutron Electronics Co., Inc. | Load control system having an energy savings mode |
US9124130B2 (en) | 2009-07-30 | 2015-09-01 | Lutron Electronics Co., Inc. | Wall-mountable temperature control device for a load control system having an energy savings mode |
US8866343B2 (en) | 2009-07-30 | 2014-10-21 | Lutron Electronics Co., Inc. | Dynamic keypad for controlling energy-savings modes of a load control system |
US8901769B2 (en) * | 2009-07-30 | 2014-12-02 | Lutron Electronics Co., Inc. | Load control system having an energy savings mode |
US8975778B2 (en) | 2009-07-30 | 2015-03-10 | Lutron Electronics Co., Inc. | Load control system providing manual override of an energy savings mode |
US8946924B2 (en) | 2009-07-30 | 2015-02-03 | Lutron Electronics Co., Inc. | Load control system that operates in an energy-savings mode when an electric vehicle charger is charging a vehicle |
US20110050451A1 (en) * | 2009-09-03 | 2011-03-03 | Lutron Electronics Co., Inc. | Method of selecting a transmission frequency of a one-way wireless remote control device |
US8598978B2 (en) | 2010-09-02 | 2013-12-03 | Lutron Electronics Co., Inc. | Method of configuring a two-way wireless load control system having one-way wireless remote control devices |
EP2733299B1 (en) | 2011-03-11 | 2015-09-02 | Lutron Electronics Co., Inc. | Motorized window treatment |
WO2013003813A1 (en) | 2011-06-30 | 2013-01-03 | Lutron Electronics Co., Inc. | Device and method of optically transmitting digital information from a smart phone to a load control device |
WO2013012547A1 (en) | 2011-06-30 | 2013-01-24 | Lutron Electronics Co., Inc. | Load control device having internet connectivity, and method of programming the same using a smart phone |
US9544977B2 (en) | 2011-06-30 | 2017-01-10 | Lutron Electronics Co., Inc. | Method of programming a load control device using a smart phone |
US9368025B2 (en) | 2011-08-29 | 2016-06-14 | Lutron Electronics Co., Inc. | Two-part load control system mountable to a single electrical wallbox |
US10006462B2 (en) | 2012-09-18 | 2018-06-26 | Regal Beloit America, Inc. | Systems and method for wirelessly communicating with electric motors |
US10019047B2 (en) | 2012-12-21 | 2018-07-10 | Lutron Electronics Co., Inc. | Operational coordination of load control devices for control of electrical loads |
US10244086B2 (en) | 2012-12-21 | 2019-03-26 | Lutron Electronics Co., Inc. | Multiple network access load control devices |
US9413171B2 (en) | 2012-12-21 | 2016-08-09 | Lutron Electronics Co., Inc. | Network access coordination of load control devices |
US10135629B2 (en) | 2013-03-15 | 2018-11-20 | Lutron Electronics Co., Inc. | Load control device user interface and database management using near field communication (NFC) |
ES2822475T3 (en) * | 2015-05-07 | 2021-05-04 | Ingenieria Wiseconn S A | Water or other fluid management system and procedure |
US10317100B2 (en) | 2016-07-22 | 2019-06-11 | Ademco Inc. | Simplified schedule programming of an HVAC controller |
US10268818B2 (en) | 2016-09-07 | 2019-04-23 | Vivint, Inc. | Automated script |
US11372387B2 (en) * | 2020-03-03 | 2022-06-28 | Charter Communications Operating, Llc | Metadata-based smart home automation |
US11946565B2 (en) | 2021-02-25 | 2024-04-02 | Hayward Industries, Inc. | Valve assembly |
US11204106B1 (en) | 2021-02-25 | 2021-12-21 | Valve Technologies, LLC | Valve assembly |
US11137780B1 (en) | 2021-02-25 | 2021-10-05 | Valve Technologies, LLC | Fluid distribution manifold |
US11579636B2 (en) * | 2021-04-22 | 2023-02-14 | Hayward Industries, Inc. | Systems and methods for controlling operations of multi-manifold fluid distribution systems |
Citations (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5278977A (en) * | 1991-03-19 | 1994-01-11 | Bull Hn Information Systems Inc. | Intelligent node resident failure test and response in a multi-node system |
US5307490A (en) * | 1992-08-28 | 1994-04-26 | Tandem Computers, Inc. | Method and system for implementing remote procedure calls in a distributed computer system |
US5664101A (en) * | 1993-12-22 | 1997-09-02 | Heidelberg Druckmaschinen Ag | Intelligent industrial local area network module for use in a distributed control system |
US5697436A (en) * | 1995-04-19 | 1997-12-16 | E. I. Du Pont De Nemours And Company | Proportional with variable bias batch reactor temperature control system |
US5956515A (en) * | 1997-07-22 | 1999-09-21 | International Business Machines Corporation | Method for managing multiple versions of multiple subsystems in a distributed computing environment |
US6047311A (en) * | 1996-07-17 | 2000-04-04 | Matsushita Electric Industrial Co., Ltd. | Agent communication system with dynamic change of declaratory script destination and behavior |
US6055363A (en) * | 1997-07-22 | 2000-04-25 | International Business Machines Corporation | Managing multiple versions of multiple subsystems in a distributed computing environment |
US6192282B1 (en) * | 1996-10-01 | 2001-02-20 | Intelihome, Inc. | Method and apparatus for improved building automation |
US6272524B1 (en) * | 1999-01-07 | 2001-08-07 | Iq Netsolutions Inc. | Distributed processing systems incorporating a plurality of cells which process information in response to single events |
US6272527B1 (en) * | 1999-01-07 | 2001-08-07 | Iq Net Solutions, Inc. | Distributed processing systems incorporating nodes having processing cells which execute scripts causing a message to be sent internodally |
US20020016639A1 (en) * | 1996-10-01 | 2002-02-07 | Intelihome, Inc., Texas Corporation | Method and apparatus for improved building automation |
US20020035404A1 (en) * | 2000-09-14 | 2002-03-21 | Michael Ficco | Device control via digitally stored program content |
US20020111698A1 (en) * | 2001-02-09 | 2002-08-15 | Marco Graziano | Web-based system for monitoring and/or controlling home devices |
US6505087B1 (en) * | 1997-11-10 | 2003-01-07 | Maya Design Group | Modular system and architecture for device control |
US20030065407A1 (en) * | 2000-04-28 | 2003-04-03 | Echelon Corporation | Internet based home communications system |
US20030199999A1 (en) * | 2001-11-08 | 2003-10-23 | Compass Technologies, Inc. | Method and apparatus for providing a dynamically programmable field controller |
US6792337B2 (en) * | 1994-12-30 | 2004-09-14 | Power Measurement Ltd. | Method and system for master slave protocol communication in an intelligent electronic device |
US20040215694A1 (en) * | 2003-03-26 | 2004-10-28 | Leon Podolsky | Automated system and method for integrating and controlling home and office subsystems |
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 |
US6832343B2 (en) * | 1999-08-20 | 2004-12-14 | Pilz Gmbh & Co. | Apparatus for controlling safety-critical processes |
US20040260407A1 (en) * | 2003-04-08 | 2004-12-23 | William Wimsatt | Home automation control architecture |
US7024450B1 (en) * | 1997-10-06 | 2006-04-04 | Mci, Inc. | Method and apparatus for deploying service modules among service nodes distributed in an intelligent network |
US7213061B1 (en) * | 1999-04-29 | 2007-05-01 | Amx Llc | Internet control system and method |
-
2003
- 2003-04-24 US US10/422,525 patent/US7089066B2/en not_active Expired - Lifetime
-
2004
- 2004-04-23 WO PCT/US2004/012345 patent/WO2004097557A2/en active Application Filing
-
2006
- 2006-08-07 US US11/462,749 patent/US20060271204A1/en not_active Abandoned
Patent Citations (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5278977A (en) * | 1991-03-19 | 1994-01-11 | Bull Hn Information Systems Inc. | Intelligent node resident failure test and response in a multi-node system |
US5307490A (en) * | 1992-08-28 | 1994-04-26 | Tandem Computers, Inc. | Method and system for implementing remote procedure calls in a distributed computer system |
US5664101A (en) * | 1993-12-22 | 1997-09-02 | Heidelberg Druckmaschinen Ag | Intelligent industrial local area network module for use in a distributed control system |
US6792337B2 (en) * | 1994-12-30 | 2004-09-14 | Power Measurement Ltd. | Method and system for master slave protocol communication in an intelligent electronic device |
US5697436A (en) * | 1995-04-19 | 1997-12-16 | E. I. Du Pont De Nemours And Company | Proportional with variable bias batch reactor temperature control system |
US6047311A (en) * | 1996-07-17 | 2000-04-04 | Matsushita Electric Industrial Co., Ltd. | Agent communication system with dynamic change of declaratory script destination and behavior |
US6192282B1 (en) * | 1996-10-01 | 2001-02-20 | Intelihome, Inc. | Method and apparatus for improved building automation |
US20020016639A1 (en) * | 1996-10-01 | 2002-02-07 | Intelihome, Inc., Texas Corporation | Method and apparatus for improved building automation |
US5956515A (en) * | 1997-07-22 | 1999-09-21 | International Business Machines Corporation | Method for managing multiple versions of multiple subsystems in a distributed computing environment |
US6055363A (en) * | 1997-07-22 | 2000-04-25 | International Business Machines Corporation | Managing multiple versions of multiple subsystems in a distributed computing environment |
US7024450B1 (en) * | 1997-10-06 | 2006-04-04 | Mci, Inc. | Method and apparatus for deploying service modules among service nodes distributed in an intelligent network |
US6505087B1 (en) * | 1997-11-10 | 2003-01-07 | Maya Design Group | Modular system and architecture for device control |
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 |
US6272527B1 (en) * | 1999-01-07 | 2001-08-07 | Iq Net Solutions, Inc. | Distributed processing systems incorporating nodes having processing cells which execute scripts causing a message to be sent internodally |
US6272524B1 (en) * | 1999-01-07 | 2001-08-07 | Iq Netsolutions Inc. | Distributed processing systems incorporating a plurality of cells which process information in response to single events |
US7213061B1 (en) * | 1999-04-29 | 2007-05-01 | Amx Llc | Internet control system and method |
US6832343B2 (en) * | 1999-08-20 | 2004-12-14 | Pilz Gmbh & Co. | Apparatus for controlling safety-critical processes |
US20030065407A1 (en) * | 2000-04-28 | 2003-04-03 | Echelon Corporation | Internet based home communications system |
US20020035404A1 (en) * | 2000-09-14 | 2002-03-21 | Michael Ficco | Device control via digitally stored program content |
US6868292B2 (en) * | 2000-09-14 | 2005-03-15 | The Directv Group, Inc. | Device control via digitally stored program content |
US20020111698A1 (en) * | 2001-02-09 | 2002-08-15 | Marco Graziano | Web-based system for monitoring and/or controlling home devices |
US20030199999A1 (en) * | 2001-11-08 | 2003-10-23 | Compass Technologies, Inc. | Method and apparatus for providing a dynamically programmable field controller |
US20040215694A1 (en) * | 2003-03-26 | 2004-10-28 | Leon Podolsky | Automated system and method for integrating and controlling home and office subsystems |
US20040260407A1 (en) * | 2003-04-08 | 2004-12-23 | William Wimsatt | Home automation control architecture |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080126778A1 (en) * | 2006-08-30 | 2008-05-29 | Bishop Bradley W | System and method for applying a destructive firmware update in a non-destructive manner |
US7823020B2 (en) * | 2006-08-30 | 2010-10-26 | International Business Machines Corporation | System and method for applying a destructive firmware update in a non-destructive manner |
US20120011488A1 (en) * | 2009-05-22 | 2012-01-12 | Noriaki Suzuki | Script description separation reconstructing device, script description separation reconstructing method, and non-transitory computer readable medium storing script description separation reconstructing program |
US9032365B2 (en) * | 2009-05-22 | 2015-05-12 | Nec Corporation | Script description separation reconstructing device, script description separation reconstructing method, and non-transitory computer readable medium storing script description separation reconstructing program |
US20110245938A1 (en) * | 2010-04-01 | 2011-10-06 | ESI Ventures, LLC | Modular centralized lighting control system for buildings |
US9173267B2 (en) * | 2010-04-01 | 2015-10-27 | Michael L. Picco | Modular centralized lighting control system for buildings |
US20110270417A1 (en) * | 2010-04-28 | 2011-11-03 | Kabushiki Kaisha Toshiba | Control system and control method |
US8483847B2 (en) * | 2010-04-28 | 2013-07-09 | Kabushiki Kaisha Toshiba | Control system and control method |
US20130304259A1 (en) * | 2012-05-09 | 2013-11-14 | Honeywell International Inc. | Airflow and water balancing |
US9441848B2 (en) * | 2012-05-09 | 2016-09-13 | Honeywell International Inc. | Airflow and water balancing |
WO2014182623A1 (en) * | 2013-05-09 | 2014-11-13 | Siemens Industry, Inc. | Interface for adjustment of portions of a building automation system |
WO2018034575A1 (en) * | 2016-08-16 | 2018-02-22 | Darc Technologies Limited | A power line carrier transceiver, distributed automation system, and methods of operation |
Also Published As
Publication number | Publication date |
---|---|
US7089066B2 (en) | 2006-08-08 |
WO2004097557A3 (en) | 2005-05-12 |
WO2004097557A2 (en) | 2004-11-11 |
US20040215778A1 (en) | 2004-10-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20060271204A1 (en) | Hot Reprogrammability of Building Automation Devices | |
US7650323B2 (en) | CAN communication for building automation system | |
US7433740B2 (en) | CAN communication for building automation systems | |
KR100434292B1 (en) | Home Network System | |
US9377768B2 (en) | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network | |
US20040111490A1 (en) | Home network system and method for operating the same | |
US7126291B2 (en) | Radio frequency lighting control system programming device and method | |
US8761945B2 (en) | Device commissioning in a heating, ventilation and air conditioning network | |
US6615088B1 (en) | System and method of device interface configuration for a control system | |
US8437877B2 (en) | System recovery in a heating, ventilation and air conditioning network | |
US8600558B2 (en) | System recovery in a heating, ventilation and air conditioning network | |
US8452906B2 (en) | Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network | |
US20040218591A1 (en) | Bridge apparatus and methods of operation | |
US20100106815A1 (en) | Memory recovery scheme and data structure in a heating, ventilation and air conditioning network | |
US20100106325A1 (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 | |
JP2003009261A (en) | System and method for building routing table and for routing signal in automation system | |
WO2006135726A2 (en) | Software architecture system and method for communication with, and management of, at least one component within a household appliance | |
US20080196023A1 (en) | Local controller, remote management controller and method for automatically updating the local controller of an air conditioner system | |
US7499978B2 (en) | Apparatus for restoring network information for home network system and method thereof | |
CN114172756A (en) | Version upgrading method and system for intelligent equipment electronic control firmware | |
KR100505537B1 (en) | Home network developing system and its operating method | |
JP2008042399A (en) | Wireless network system | |
KR100437797B1 (en) | Method for assigning network manager of home network | |
KR100292880B1 (en) | Method for confirming processing state of control command |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: COLORADO VNET, LLC, COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HESSE, SCOTT;KIWIMAGI, GARY;OGAWA, CRAIG;REEL/FRAME:018062/0406 Effective date: 20060804 |
|
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 |