AU7956098A - Distributed control using group concepts - Google Patents

Description

WO 98/57239 PCT/US98/11843 -1 DISTRIBUTED CONTROL USING GROUP CONCEPTS BACKGROUND OF THE INVENTION The decreasing cost of microcontrollers for use in control systems has led to the recent trend from centralized control systems to distributed control systems in many 5 applications. Unfortunately, the distributed control system retains the legacy of a complicated installation and configuration process required for typical centralized control systems. In fact, decentralized control possibly complicates this already difficult process. Older control systems made use of a centralized controller to control or receive 10 data from a number of physical components, such as light switches, lamps, thermostats and heat exchangers or other devices which monitor or control the environment in a system, or are controlled by another component in the system which controls the environment. The high cost of controllers and development costs often drove designers to develop control systems designed to work with as many types of physical 15 components and configurations as possible. This design choice led to savings on system, development, and hardware costs, but caused a burdensome complexity in system installation and configuration. With movement to distributed control, a controller assigned to each physical component automatically handles communication with the physical component it 20 controls, but communication between controllers in the system is not any less complicated than in centralized control systems. Distributed control complicates installation and configuration because rather than a single controller to program and configure, numerous decentralized controllers must be programmed and configured. Furthermore, in the centralized control system, communication with physical 25 components would be relatively simple and typically subject to accepted standards. Controller communications can be complicated and are not regulated by widely accepted standards. Thus configuration of the controllers in a distributed control system remains a significant cost, in terms of both time and money for initial installation, and a deterrent 30 to reconfiguration of the system after initial installation. Initial installation cost is high because the installer must be familiar with how the controller is to be programmed, and also familiar with each type of physical component connected to the controller. System WO 98/57239 PCT/US98/11843 -2 modifications after installation are not attractive because the system would again need to be reconfigured by someone with the necessary data about the physical component in the system and how to program each controller. In fact, after-installation, modification of the system is likely to be more costly and time-consuming since the system may be 5 old when reconfiguration occurs, and there may be fewer people available who are still skilled in programming the control devices. Thus, a system which eliminates or reduces the complexity of the installation and configuration process would be a significant improvement to the overall cost of current control systems. Such a system would be even more effective if it could allow 10 addition of new components to the control system after initial system installation to be performed by individuals with no specialized knowledge about the control system or its components. One possible response to the configuration problem would be to design a set of devices capable of self-configuration. To some extent, the concept of self-configuration 15 has been applied in the computer configuration area, under the term "plug-and-play". However, in the computer area, devices rely on the computer's processor to handle device configuration. In an ideal system, the devices in the system would be able to self-configure without the help of a centralized control device. 20 SUMMARY OF THE INVENTION The applicant's invention provides the desired control system, using a set of devices capable of self-configuration. Each device in the system communicates with other devices in the system using a communication infrastructure to determine which of the other devices can supply the data it needs to function. Each device can 25 communicate with each other device to determine what data that device can supply to other devices on the communication infrastructure, and to determine which other devices can supply data that the device needs to operate. The invention is independent of the means for communicating between the devices. An apparatus operating within the above system is also described in this application. 30 A method of the present invention, includes the steps of: (1) attaching a device to a communication infrastructure, and (2) allowing that device to communicate with other devices--i.e. without an intermediary device--on the communication infrastructure WO 98/57239 PCT/US98/11843 -3 to determine what data the device can supply to other devices, and to determine from which other device it may obtain data it needs to operate. The applicants' invention can be expanded to more complicated systems by separating the various devices into functional groups, and performing the applicants' 5 self-configuration and operational method to these associations of devices, rather than all devices within the system. This adaptation eliminates possible confusion among similar devices in the same system, and allows the applicants' system of self configuration to function in those more complicated systems. 10 BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a diagram of a simple system to be controlled by the applicants' invention. Figure 2 is a block diagram of several devices utilizing the applicants' invention, and the associated communication infrastructure between devices in the system. 15 Figure 3 is a flow diagram for one possible self-configuration process of the applicants' invention. Figure 4 is a diagram of an extension of the applicants invention utilizing grouping concepts. Figures 5 is a more complicated version of the applicants' invention involving 20 grouping concepts. Figure 6 is a flow diagram for one possible self-configuration process of the applicants' invention, utilizing grouping concepts. Figure 7 is a simple system of groups used in describing one implementation of the applicants' invention. 25 DETAILED DESCRIPTION OF THE INVENTION Figure 1 illustrates a simple group of devices 1. In the group there are 5 devices, two of type A and one each of types B, C, and D. All the devices may be associated with a room or other space RM1. Physically, device type A might be a light switch 30 device mounted on a wall, which was designed to operate with a lamp, represented by device C, in the ceiling of the same room. Device type B might be a thermostat also on the wall which is designed to operate with a heat exchanger represented by device type WO 98/57239 PCT/US98/11843 -4 D. As a group these devices will control the environment of the space they occupy by exchanging information among each other. Device C will use the status of the light switches in the two A devices in order to turn the lamp on or off. Device D will use the temperature and setpoint data obtained from device B to control the temperature of the 5 space RM 1. Figure 2 shows block diagrams and the interconnections for devices of the type utilized in the applicants' system. Devices 2 and 6 in Figure 2 represent type A switch devices from above, and device 3 a type C lamp device. Devices 4 and 5 represent devices of types B and D, respectively. Internally, device 2 is composed of 10 communication component 2A, device controller 2B, physical component 2C, and memory component 2D. Each of the other devices 3, 4, 5, and 6 contains a similar set of internal components performing similar, but in most cases, not identical functions. Communication component 2A handles communication with other devices on communication infrastructure 7 and with the device controller. In a particular 15 application the communication component may even be part of the device controller itself. The communication component may also include or be comprised of its own processor for handling communication. For a particular application, block 2A may take on any form convenient or cost effective to interface the devices together. The communication component may also play a vital role, along with the device controller 20 in device self-configuration, to be described later. The device controller sends and receives data to the communication component and the physical component, and makes necessary control decisions. The device controller also updates the memory component with any data received from the physical component or the communication component. 25 Memory component 2D stores self-configuration data created by the communication component or the device controller during the self-configuration process. In a real application, the memory component may actually be implemented within the device controller. Conceptually, the memory component is used by the device controller and communication component to store information about devices in 30 the system, information about the types of data which are needed or which can be supplied by the device, the location of data in other devices which the device uses for operation, and the location of devices which have requested data from the device and the WO 98/57239 PCT/US98/11843 -5 type of data requested by this device. Other information stored may also be stored in the memory component which relates to the chosen communication component or method chosen, and other factors. When the applicants' invention is expanded with the idea of groups, for example, the memory will also contain information about group 5 members and the group associations of data to be supplied or requested by a device. As in prior art systems, the physical component, such as light switches, lamps, thermostats and heat exchangers or other devices, monitor or control the environment in a system, or are controlled by another component in the system which controls the environment. The physical component, more generally be though of as an interface to 10 the environment. For example, in device 2 of Figure 2, the physical component 2C is the light switch. Some devices may actually comprise several physical components working together. In device 3 for instance, the physical component 3C is the lamp and an associated relay 3E for actuating the lamp. The lamp and the relay in this case may be referred to as a single physical component called "the lamp" although there are 15 actually several separate physical components involved. Each device is connected to communication infrastructure 7 shown in Figure 2 via its communication component. The communication infrastructure is used by all devices in the system to communicate with all other devices in the system. This communication infrastructure may be of any type which allows two-way 20 communication between each of the devices in the system, and is capable of allowing each device to initially recognize and uniquely identify each other device in the system. The applicants' have, for example, implemented prototype systems both in a simulated P.C. environment and LonWorksT based hardware. If very large systems are contemplated, a system adaptable to the use of routers or other large-system 25 communication devices may be the best choice. In smaller systems, a simple unique address for each device, and a serial communication bus may be sufficient. Wireless communication is also possible, and would likely be preferable in systems having devices which are distant from each other. The applicants' reiterate however, that the invention is independent of the communication infrastructure used, and the system 30 designer may choose whatever communication methodology he/she thinks prudent. Transfer of data between devices during self-configuration, and once self configuration is complete using the chosen communication infrastructure may take on a WO 98/57239 PCT/US98/11843 -6 number of different formats. In a preferred embodiment, devices which require data may communicate directly--i.e. without an intermediary device--between each device and another device with other devices in the system to request data. When communicating directly with another device, a unique address determined during self 5 configuration is used to send messages specifically to that device. Alternately, a device needing data may broadcast the request to all devices. When broadcasting, no particular device is addressed in the communication infrastructure, rather, all devices are sent the same message. Similarly, devices which supply data may provide this data directly to a requesting device, or may broadcast this data to all devices. Devices which 10 can supply data may also ask individual devices what data they need, or broadcast what data they have to all devices in the system. The only requirement for any of these processes is that each device identify all possible sources of data available to it, and that this data be provided, when necessary, to the requesting device. In a particular implementation, broadcasts may occur in a number of fashions. 15 One typical method would be to assign two addresses to each device. A device would then monitor either address for messages to which it may respond. One of the addresses would be a unique address for that device, which is used for direct device-device communications. This unique address would be determined during the self configuration process. The second address would be an address common to all devices, 20 chosen during system design. In order to broadcast to all devices, the sending device would use the common address to send the message. Each device in the system would subsequently receive the message since all devices share this address. To send a message to a specific device, the unique address determined during self-configuration would be used instead. 25 Every device in the system either supplies or requests data from other devices in the system, or both requests and supplies data to other devices in the system. Each piece of data or data item which can be supplied by a device in the system is identified with a unique code. Preferably, these codes are standardized across all systems and manufacturers to maximize versatility and interchangability of devices in various 30 systems. A list of the codes relevant to a particular device are programmed into each device when it is designed. Devices which need the data associated with the code will use the code during self-configuration to find a source for that data. Devices which WO 98/57239 PCT/US98/11843 -7 supply data in the system will use the code during self-configuration to recognize a request from another device for a type of data that that device can supply. It is therefore critical that each piece of data have a completely unique identifier, and that there be no ambiguity about which of the devices in the system will supply the desired data. 5 Data which can be used by a device is considered either necessary or optional data. Necessary data is data which the device requires to operate in the system. Optional data may improve the ability of a device to operate in the system, but the device can still operate without this data. A thermostat device, for example, which does not include an internal thermometer needs an actual temperature reading to be able to 10 operate at all. The temperature data would therefore be considered necessary data. Setback data on the other hand, which could be used to optimize system energy efficiency, would be considered optional data. Some data may be considered either optional or necessary data, depending on system or design choices. A temperature setpoint value in the thermostat device could for instance, be optional data if a default 15 temperature setpoint (e.g. 25 0 C) is provided internal to the thermostat device. Alternatively, the setpoint value may be considered necessary by the system designer, and thus the device would not be allowed to operate until a setpoint value was acquired from another device in the system. The applicants' contemplate that the system will not be limited by the types of 20 devices or data in a particular system, or the attributes of the particular devices. So far, the applicants' have identified simple devices, such as lamp devices and light switch devices, with simple operation (e.g. only an "on" and "off' state), and more complicated devices, such as a thermostat device, which at the least will include input for desired and actual temperatures. Other devices, by way of example, might be dimmer switches for 25 the lamp device, energy conservation devices such as load shedding devices, security monitoring devices, emergency monitoring devices, automatic locking or unlocking systems, lawn sprinkler systems, air damper device units, air exchange devices, blower control units, or low-voltage lighting or appliance systems. Each of these devices may be as complicated or as simple as desired, as long as the data supplied or requested by 30 each device is capable of identification by other devices in the system via the common list of data types.

WO 98/57239 PCT/US98/11843 -8 The applicants' also specifically note that some devices may serve as interfaces to prior-art type control systems, or be capable of operating both as self-configuring devices and as devices requiring manual configuration. These type of devices would certainly be desirable to allow the applicants' system to be installed into existing control 5 environments. Self-configuring devices of this type could then also be added to a system as prior-art-type devices are replaced due to failure or for other reasons. In the simplest of devices of the applicants' system, no manual device configuration need be required. Some manual configuration may however be desirable in some devices and systems. For example, the installer may want to provide default 10 temperature setpoints to a thermostat device, or be able to select among a number of control algorithms for a thermostat device. These types of configuration options could easily be implemented with external switches or dials on the exterior of the device. Described later, the concept of assigning devices to functional or locational groups provides an extremely valuable extension to the applicants' invention, and can also be 15 implemented using simple manual device configuration. In the system described so far, no two devices in a system can require the same type of data, each from different sources. This is necessary because self-configuration of the system requires that there be no ambiguity regarding which devices should operate with which other devices in the system. For example, a system including two 20 lamp devices and two light switch devices, one light switch device to control each lamp device would be disallowed in the system so far described. Later, when the concept of grouping is applied to the applicants' system, ambiguity among devices in the system will be possible. At this point, it will only be noted that grouping allows a large number of devices having similar or identical functions to operate on the communication 25 infrastructure, and self-configure, if devices which might be confused are placed in different groups. Removing the concept of grouping temporarily from our discussions, the applicants' invention does allow for more than one device to receive the same data from another device, and for multiple devices to supply the same data to a single device. 30 "Same data" may be thought of as data which comes from different devices but which has an identical data identifier. For multiple devices to receive data from a single device would require that the device supplying data keep track of all devices requesting that WO 98/57239 PCT/US98/11843 -9 data. This situation would not create any confusion during the self-configuration process. In a system in which multiple devices will supply the same data to the same device, the device which receives the duplicate data must have the capability to select among copies of the data, or combine the duplicated data before using it. For example, 5 a heat exchange device may receive actual temperature data from both a thermostat device and an independent thermometer unit. In such a situation, the heat exchange device may combine the two sources of data such as by averaging, filtering, or selecting the higher or lower value of the two. A second example of a system which identifies more than one device which 10 supplies the same data might be two light switch devices in a room with a single lamp device. The lamp device in this system must recognize that both light switch devices are to operate the light bulb. During self-configuration, the lamp device would recognize both switches as possible sources of data. The device controller associated with the lamp device would need to make changes in how it operates based on a change 15 in either switch. Specifically, the device controller for the lamp device must recognize that a change in the position of either switch should result in the lamp device also changing state. This concept can of course be expanded to three, four, or any number of additional switches and a single lamp device without further complication of the device controller or the system. As one in the electrical field will note, implementation of a 20 system including three or more light switch devices to control a single lamp device, in a typical present-day system, is a mind-boggling task at best. A general self-configuration strategy used in the applicant's invention is now described. Reference may be made to the flow chart of Fig. 3 for this process. The flow chart primarily shows actions taken by the new device when it is connected to the bus. 25 However, where an action is taken by another device in response to an action taken by the new device, the other device's action is indicated using a box divided into a left and right part, such as 300A and 300B. In this box, the left side of the box will indicate the action taken by the new device, and the right half of the box will indicate the response by the responding device. 30 Initially, each device is only aware of the data it can provide, the data it desires, and the existence of a communication bus on which it can request data. Each item of data which will be provided by another device, referred to as external data, should have WO 98/57239 PCT/US98/11843 - 10 a predefined default setting such that reasonable and safe control can be performed by the device without the data, or the device should remain inactive until self-configuration is complete. A heat exchange device, for example, could include a default setting which will be used until a thermostat device is found. The default setpoint temperature may 5 place the heat exchange device at a default setpoint temperature, such as 25 0 C. A lamp device on the other hand should remain in an "off" state until it finds a proper switch device. The operation of a device may then be modified to optimize device operation, once a desired source of data has been identified. Upon the new device being connected to a communication infrastructure such as 10 a communication bus, and receiving power, the new device should locate a unique address for itself from all other devices in the system. If devices such as Ethernet cards are used, which are assigned a unique address when manufactured, locating a unique address may not be necessary. However, assignment of a unique address during self configuration ensures that each device has a unique address. It also forces the addresses 15 to be sequential, and standardized, which may ease device design. At step 300A in Figure 3, the new device in the system broadcasts a request for the current high address -that is, this request is sent to all devices on the common bus, rather than to an individual device. The device which holds the current high address will respond with its address directly to the broadcasting device at step 300B. The new device will then 20 increment the received address, assume this unique address as its own in step 310, and then broadcast this address as the new high address at step 314A. All devices store a copy of the high address, at step 314B. This allows any device on the system to assume the high address if it detects that the device assigned to the stored high address is not responding to high address requests. As described shortly, this is accomplished by each 25 device keeping track of the number of address between its address and the high address, and comparing this value with the number of times a new device requests the high address and does not receive a response. Storage of the unique address may simply be in the device's memory component, or it may be in a particular location reserved for the address, or both. 30 If the current high addressed device is not available on the bus, or this is the first device connected to the bus, a procedure is required to cover this eventuality. The requesting device will wait for some period of time for the response to its request for WO 98/57239 PCT/US98/11843 -11 high address at step 302. If no reply is received, then a retry counter is incremented and the request is sent again at step 304A. The request for the address, in this case would include the retry counter. As indicated, every other device on the bus stores the current high address in step 314B, (that is why the new high address is broadcast when 5 assigned) and also a number indicating the difference between its own address and the current high address. Whenever a request for high address message is received, each device compares this difference with the retry counter in the message. If the difference is greater or equal to the retry counter, then that device will respond with the current high address at step 304B. This process will repeat for a number of retries set by the 10 device designer, with the new device checking for a response on each retry in step 306. If no response is received after some number of retries, checked in step 308, the requesting device will assume that it is alone on the bus and automatically assign a starting address to itself in step 312. Once a unique address is assigned to the device, the actual self-configuration sequence starts. 15 First, the new device checks to see if it wants data from another device in step 318. If so, the new device requests each device in the system to identify itself at step 322A. As each devices responds in step 322B, the new device stores each device's address in its memory component at step 326. A device not requiring data from another device waits for requests from other devices for data they might need at step 316. 20 If the new device desires data from other devices, it uses its compiled list of devices to request from each device each piece of data it needs, using the unique code for that data at step 328A. If a device can supply the requested data, it will respond to the new device with its own address and the unique code for the data it can supply at step 328B. The new device will store in its memory component the unique address of 25 the device supplying the requested data, and the unique code associated with this data at step 332. The device supplying the data will store the address of the new device, and the unique code for the data requested also at step 328B. Storage of this information allows the requesting and supplying device to later exchange this information when it changes, or at periodic intervals. 30 Other devices in the system subsequently request from the new device data they need, if any, at step 316. At step 320, if the new device cannot supply the data requested, it will ignore the request. If the new device can supply requested data, the WO 98/57239 PCT/US98/11843 - 12 new device will respond to the request at step 324. The new device stores in its memory component the requesting device's address and unique code for data it desires from the new device. The new device then sends response to the requesting device, indicating it can supply this information at step 320A. Upon receiving this response at step 320B, 5 the requesting device stores in its own memory component the address of the new device and the unique code for the data the new device will supply. A device which does not find all the sources of data it needs may retry periodically for a period of time to find this data before timing out and producing some external indication of its failure to find needed data at steps 334 and 336. Other data, 10 which a device requests but is not necessary for its operation, may simply be periodically searched for on the system at step 336. For example, a temperature control device or air exchanger may request an outdoor humidity measurement. The device controller in the device may include a control equation, including a humidity term. If a humidity value is not found, this humidity term may be given a default value, or left out 15 of the equation entirely. The term will be added back in if a humidity device becomes available on the system at some later time and is recognized by the temperature control device or air exchanger device. How often a device retries will be determined by the system designer, or possibly the installer as a manual configuration option. A retry may be implemented by re-running the configuration above, periodically until the necessary 20 data is found. Once a device commences operation, and completes self-configuration, requested data may either by sent individually to the requesting device periodically, or may be broadcast to all devices. Grouping Concepts 25 The addition of grouping concepts to the applicants' invention will now be described. While the system so far described will work well in simple systems involving a small number of unique devices, it cannot handle a system in which two devices in a system require the same type of data, each from different sources. For example, in a control system for an entire house, there may be more than a 30 dozen light switch devices, thermostat devices for each floor or room, and numerous damper devices or heat exchange devices. If all of these devices are placed on the communication infrastructure, self-configuration would not be possible using the system WO 98/57239 PCT/US98/11843 -13 described so far. Each lamp device searching for a light switch device would find all light switch devices in the system, and each heat exchange device would find all thermostat devices in the system. The light switch devices in a particular room, in fact, should only be recognized by the lamp device in that room, and the heat exchange 5 device in a room should only be recognized by the thermostat device in that room. Grouping provides a means for dealing with these situations when using the applicants' self-configuration method. In a system with grouping, each device is assigned to one or more groups within the system by placing a group identifier or group identifiers in the device controller or 10 memory component. For example, all light switch devices and the lamp device in one room might be assigned to group RM1. Similarly, the space heater device and the thermostat device in that room might be assigned to group RM1 as well. The group identifier may consist of the text RM1 or may be a numeric identifier which the system installer associates with RM1. 15 The restrictions which were applied to the simple system described earlier in this application are now applied instead to each group of devices, rather than the system as a whole. Specifically, no two devices in a group may require the same type of data from different sources. If a room is to have two lamp devices operating from different switch devices, the lamp devices must each be placed into separate groups. A group RM1N 20 and a group RM1S, each assigned to one of the lamp devices, for instance, would provide the necessary separation of the two lamp devices. One switch device would then be assigned to each of these groups, eliminating any ambiguity as to which switch device should control which lamp device. While so far the grouping concept has been described in terms of rooms being 25 groups, the groupings should generally be decided based on which components it makes sense to group together. All devices which operate in an air handling unit, for example, would be one possible grouping. Grouping might also make sense based on floor, house, fire-related devices, security-related devices, or other groupings prudent for a particular situation. 30 As indicated, a particular device may be a member of more than one group, and the same device or same type of device may belong to more than one group. Consider for example, the system of groups shown in Figure 4. There are three groups identified, WO 98/57239 PCT/US98/11843 -14 FL 1, RM1, and AHUl. A device of type A, A, B, C, and D are all members of group RM1. Devices of type E, F, G, A, and H comprise the members of group AHU1. The device H from group AHU1 and the device D from group RM1 are also members of group FL1. One will note from the figure that there are three apparently identical device 5 A's in the system; there are two A devices in group RM1, and one type A device in group AHU 1. Due to the chosen grouping there is no confusion about which devices will use data from which type A device. In group RM 1, both A devices will perform exactly the same function. As described earlier, since these two identical devices will be found by the same requesting devices, a change in the state of either A device will be 10 reflected by the requesting device receiving data from these devices. The A device in group AHUI will only operate with devices in its own group and will not be confused with the A devices in RM1 because of its group identifier. Devices D and H belong to more than one group to allow interaction between the two groups, without requiring all devices in both groups to be in the same group. (At 15 the very least, this would cause confusion among the type A devices in both groups.) Device D for instance, might be a thermostat device and device H a heat exchange unit. The heat exchange device performs necessary temperature changes in the space associated with group RM1. Device D would, for example, consist of a central electric or gas heating device, typical in many houses. Device C in this example might be a vent 20 damper device for group RM1. The vent damper device either allows or blocks heat from the heat exchange device from entering the space associated with group RM 1. This set-up is typical, where a single heat exchange device is used to control the temperature in several spaces, each with independent temperature control device. The damper device allows the space associated with group RM 1 to be heated with the heat 25 exchange device, without also heating other spaces not requiring heat. Both devices H and C would require use of data from device D. Device C, however, is assigned to group RM1 so that it controls the damper device for that room only. Device H is a member of group AHU1 so that it works in conjunction with other devices in the system to control the temperature/air flow/humidity in a several units of space, one of which is 30 associated with group RM1. The complexity of the system, and the groupings, can be increased by having multiple devices in a group belong to multiple other groups. Such a system is shown in WO 98/57239 PCT/US98/11843 -15 Figure 5. In this figure, multiple rooms on two separate floors, FL 1 and FL2, are assigned groups. Selected devices from each of these rooms are also assigned a floor grouping based on which floor the room is on. The floor grouping may also share devices with an air handling unit group for each floor. Finally, the air handling unit 5 group for each floor may include members which belong to a system group, such as a fire or security functions group. Assignment of groups would most likely be performed as a manual configuration step just prior to installation of the devices into a system. Group assignments may be made using a set of simple DIP switch accessible on the exterior of 10 a device. This method would allow manual configuration to be fairly uncomplicated, although it would require that the installer keep track of the DIP settings for each group. As an alternative method, word or phrase group names could be used if manual configuration is done using a manual-configuration device such as a hand-held programmer, or a PC interface card. The hand-held programmer or PC interface card 15 would be used to interface with the device controller to store the group names in the memory component. As an example, the interface between the hand-held programmer or PC interface card and the device may be an RS-232 serial connection or some other chosen standard. It would also be possible to assign the group name a data type, thereby allowing a device to be given group assignments via the communication infrastructure 20 from a device designed for the purpose. While complicating the manual configuration process, this method is attractive in complicated systems with a multitude of groups, since it allows meaningful group names to be used, and likely does not as severely limit the number of groups possible. Other advantages and disadvantages of either method or variations thereof may be contemplated by the reader. 25 Modification of the applicant's invention to incorporate the grouping concept is now described. In order to implement the grouping concept, a group or groups must be assigned to each device operating on the communication infrastructure. This group may be added as part of the unique address of each device, or it may simply be a list of group names stored in the memory component of the device. The self-configuration steps 30 previously described are thereafter applied to members of a group, as determined from the memory component or the unique address, rather than all devices in the system.

WO 98/57239 PCT/US98/11843 -16 The modified method of self-configuration, including the grouping concept is shown in the flow chart of Figure 6. With grouping implemented, when a new device is connected to the communication bus, and is powered-on, a unique address is assigned, as described earlier in this application. The new device will then request members of 5 the groups it belongs to only, to identify themselves, if the new device requires data from other devices. As each device responds, the new device stores the responding device's address in its memory component, as before. The new device then requests, only from group members, any data it desires. Devices which have identified themselves as group members with the new device at this point request any needed data 10 from the new device. The remainder of the self-configuration remains the same as before. As an extension of the grouping concept, the same device can be used to perform a different control function for each group. During self-configuration, each group a device belongs to is also associated with a desired control function for that group. As an 15 example, a single heating device may control the environment in several different rooms in a house. Some rooms however, may have more critical temperature requirements than others. To allow these different spaces to be controlled differently by the same heating device, the controlled devices would be grouped by criticality of temperature requirements, and different algorithms would be assigned to each group. The single 20 heating device could then control operation of all the devices in the different groups, assuming its memory component included an association for each group, and the control algorithm to be used with that group. To implement this method would require that when a device is assigned a group name, it is also assigned a function to be associated with that group. 25 A typical embodiment using the applicants' invention and its self-configuration is now described. With reference to Figure 7, the system includes three groups, RM1, RM2, and AHU. RM1 and RM2 both contain 5 devices; light switch device 30 and 31, lamp device 32 and 33, damper device 34 and 35, thermostat device 36 and 37, and temperature control device 38 and 39. Group AHU includes six devices including both 30 temperature control devices 38 and 39 from groups RM1 and RM2, respectively. The other devices in group AHU includes blower device 40, cooling device 41, heating device 42, and air exchange device 43. In a house, the groups RM1 and RM2 would WO 98/57239 PCT/US98/11843 -17 each be associated with a separate room. The AHU group includes all the devices associated with the heating and cooling system of the house. Table 1 lists each type of data available, and an associated data ID. Table 2 lists each device in the system, and the types of data it either receives, or supplies. 5 Table 1 Data Types Data ID Switch state 1 Cool unit on/off 2 Heat unit on/off 3 Blower % to change 4 Air Exchange % to change 5 Damper device % to change 6 Temperature setpoint 7 Actual Temperature 8 Blower % open 9 Air Exchange % exchange 10 Damper device % open 11 Table 2 Device Types ID Data Type ID Data Type Supplied Requested Light 1 Light switch device 1 Temperature control device 2,3,4,5,6 7,8 Thermostat device 7,8 Cool Unit 2 Heat Unit 3 Blower 9 4 Air Exchange 10 5 Damper device 11 6 10 In the memory component of each device, tables of data similar to tables 3, 4, and 5 are created. Table 3 stores information about each data item used by a device, including both internal data -data supplied by the device's physical component, and external data -data supplied by other devices. Each data item used or supplied by a device is given an entry in this table. Internal data items in the list are parsed when 15 another device is requesting data. External data items in the list are parsed when this device is searching for a device to supply the particular data item it desires. This table will be called, and may be referred to as the Data Item Control Table. Table 3 also WO 98/57239 PCT/US98/11843 -18 contains information about what the device will do if it receives no copies, or multiple copies of the external data it requests. A number of other items in the table perform functions specific to the communication component used, in this case, Echelon hardware, using the LonWorks protocol. Details about these variables are a matter of 5 design choice and not necessary for a full understanding of the invention. It is sufficient to say that actual data sent and received by a device is stored in a communication register, one communication register for each data item used by the device. The last item in the data item control table is an index variable to the bindings for this data item in the bind control table, which is described by Table 4. 10 Table 3 Data Item Control Table Variable Description Data ID Unique Data Item identifier Source External, Internal, or Either Default Used Determines if default will be use if Data Item is not found Multiple Source Action Action to take on multiple copies of same Data Item (average, highest, lowest). Default Value Default value to use of default is used NV Index (communication component-specific) Index to register holding current value of Data Item No. External Refs. (Communication component-specific) Number of references to this Data Item by other devices. Multiple ID (Communication component-specific) Special ID used when multiple references to this Data Item by external devices. Index to Bind control Index to first external device requesting this Data table Item. Portions of the data item control table may be altered during a manual 15 configuration of the device, prior to its connection to the communication bus. Particularly, the default value, and the choice of how to deal with multiple sources of the same data may be manually configured. For simplicity, we will assume all devices will remain off until they receive all requested data, except the temperature control WO 98/57239 PCT/US98/11843 -19 devices 38 and 39, which will operate upon receiving both temperature and setpoint data, data types 8 and 7 respectively. Table 4 stores the information created during the self-configuration process about which devices will supply desired information to a device, and where it will 5 supply request information. Table 4 may be referred to as a bind control table, as it establishes binds or connections between the device containing the table and another device requesting data from this device. The bind control table includes a data ID, which is used as an index by other tables in the device. Table 4 also includes an index to the data item's entry in the Data Item Control Table, the address of the device which 10 requested or will supply the data item, and the group which that device belongs to. The bind control table also includes an index to the next entry for this data item in the bind control table. The last table, Table 5 contains a list of devices which are in the same group as this device. It includes an index variable, and the address of each group member in the system. Not all of the variables are discussed in detail below. Primarily, 15 the variables omitted from the discussion below provide indexes from one table into another, or relate to communication component-specific variables, included to show each item of data an actual table might contain. Table 4 20 Bind Control Table Variable Description Data ID Unique Data Item identifier. Var. Ctrl. Index Index to Data Item in Data Item Control Table. Address Address of device requesting/supplying Data Item. Index to Group List Index to group of device requesting/supplying Data Item. Index to Next Bnd Entry Index to the next entry in this table requesting this Data Item. Table 5 Group Members List Variable Description Index Group member list index WO 98/57239 PCT/US98/11843 - 20 Address Index to Data Item in Data Item Control Table Prior to each device being connected to the communication bus, groups are assigned to each device, using for example, a hand-held interface. The group names are parsed during the self-configuration process when another device requests group 5 members, to identify themselves. Once group members are identified, the group member list in a device is used to keep track of group members, and the group name is no longer needed. The lamp device, light switch, damper and thermostat in one room are all configured with a group name of RM1. This group name is stored in the memory 10 component of each device. The lamp device, light switch, damper and thermostat in the second room are all configured with a group name of RM2. This group name is stored in the memory component of each device. The blower device, the cooling device, the heating device, and the air exchange device are all configured with a group name of AHU. The temperature control device from each room is configured with two groups 15 each. The temperature control device in one room is configured with groups RM1 and AHU. The temperature control device in the other room is thus configured with groups RM2 and AHU. Physically, a light switch device could include two contacts, which are either in contact or not in contact. The device controller associated with the light switch device 20 monitors short/ no short between these contacts. The device controller recognizes that it can supply data of type 1, which is switch state, as indicated in Table 1. The lamp devices includes a relay, controlled by the device controller associated with the lamp device. The device controller associated with a lamp device knows it needs data of type 1 to determine what the relay should do with the switch. Initially, 25 since the device controller associated with the lamp device has no switch state data, it keeps the lamp device off. Assume that initially there are no devices on the bus, and the light switch device from group RM1 is subsequently connected to the bus, and then powered on. The device controller in this light switch device will broadcast a request for the current high 30 address via the communication component. Since no other device is on the bus, the light switch device will, after several attempts to identify the high address, assume the WO 98/57239 PCT/US98/11843 -21 first address for itself. This address is stored in the device's memory component, and is used by the device to identify itself to other devices in the system, and consequently is later the address it monitors on the bus for requests or data from other devices. The light switch device broadcasts its newly acquired address on the bus. Each device on the 5 system would normally record the broadcast address from the light switch device as the new high address. In this case, since there are no other devices in the system, the broadcast is ignored. If, the light switch device required external data, it would next request devices which are members of group RM1 to identify themselves. Since it does not require 10 external data, the lamp device takes no further action. At this point, the light switch device simply waits for other devices to be connected to the bus. The lamp device in group RM1 is subsequently connected to the bus and powered on. The lamp device will broadcast a request for the current high address. Since the light switch device was the first device on the bus, the light switch device will 15 respond directly to the lamp device, with its address. The lamp device will then increment this address, and assign this new address to itself. The lamp device will then broadcast its address. The only other device on the bus, the light switch device, will receive this broadcast, and store the address of the lamp device in its memory component since all devices keep track of the current high address. 20 The lamp device next broadcasts a request for other devices in the system belonging to group RM1 to identify themselves. In this case, the only other device on the system, the light switch device, responds with its address. The light switch device's address is stored in the lamp device's group member list table. The lamp device, upon receiving the response from the light switch device sends a request to the light switch 25 device for data of type 1, and stores the lamps device's address in its group member list as a member of group RM1. The light switch device can supply this type of data, so it responds directly back to the lamp device that it can supply this data. The light switch device then stores in its bind control table that it will supply data of type 1 to the lamp device whenever this data changes. It will also add the necessary entries to its data item 30 control table. The lamp device stores in its own bind control table the source for the data of type 1.

WO 98/57239 PCT/US98/11843 - 22 If the light switch device required external data, it would request that data from the lamp device at this time. The light switch device makes no such request however since it does not require any external data. Assume the next device to be connected to the bus is the temperature control 5 device from group RM1. The temperature control device will be responsible for making control decisions in its device controller regarding how the temperature in the space should be altered based on the data supplied to it, and the devices connected to it. The temperature control device will provide data of types 2, 3, 4, 5, and 6. Data of type 2 indicates whether the cooling device should be on or off. Data of type 3 indicates 10 whether the heating device should be on or off. Type 4 is data on desired blower speed, as a percentage of the current blower speed. Type 5 is data on air exchange amount as a percentage of current air exchange amount. Data type 6 is data on damper position as a percentage of current damper position. The temperature control device require two types of data, data of type 7, which provides a desired temperature setpoint, and data of 15 type 8, which provides an actual temperature value. When the temperature control device from RM1 is connected to the bus, it requests the current high address. The lamp device from RM1, which has the current high address, responds with its address. The temperature control device will then increment this address, and assign the incremented address to itself. The temperature 20 control device will then broadcast the new high address, and each other device on the bus will store the new high address. The temperature control device from RM 1 will next attempt to identify sources for data is desires. First, it broadcasts a request for all devices in either group RM1 or AHU to identify themselves. Each device in these groups will respond, and its address 25 will be stored in the group member list of the temperature control device. The temperature control device will then send a request for each data item it wants to each device as it responds. Specifically, the temperature control device will request data of type 7 and 8 from the lamp device and the light switch device in group RM1. Since neither device can supply either type of data, neither will send a response to the 30 temperature control device's request. Each other device in both groups RM1 and AHU will next request from the temperature control device data that that device wants. In this case, the only device WO 98/57239 PCT/US98/11843 - 23 which would request data would be the lamp device because the light switch device does not require external data to operate and no devices from group AHU are in the system yet. The lamp device desires data of type 1, and since the temperature control device does not supply data of type 1, it will not respond to the lamp device's request 5 for this data. Since the temperature control device in group RM1 received none of the data it uses to operate, it will remain inactive in the system pending other devices appearing on the system. Assume next that a thermostat device from group RM1 is connected to the bus. 10 The thermostat device consists of a temperature sensing apparatus, and a setpoint mechanism, both of which are monitored by an associated device controller. The device controller knows that it can supply data of type 7 and 8. The thermostat device does not require any data. The thermostat device from RM1 is connected to the bus and powered on. After 15 acquiring an address it will receive requests from the lamp device and the temperature control device for data since they are in the same group. The lamp device will request data of type 1, which the thermostat device cannot provide. Thus no response will be sent to the lamp device. The temperature control device in RM1 will request data of type 7 and 8, which the thermostat device can provide, and consequently the thermostat 20 device will send a response to the temperature control device, and place the necessary information about the temperature control device in its bind control table and data item control table. The temperature control device in RM1 will store the necessary information about the thermostat device in its data item control table and bind control table as the supplier of the identified data as well. The thermostat device does not 25 require any data, so it will not make a request for data from other devices on the bus. The temperature control device in RM1, having now received data it requires for operation will become active in the system. That is, it will make control decisions based on the data provided by the thermostat device in RM1. Since no devices capable of altering the temperature in the space are yet connected in to the system, the control 30 decisions made by the temperature control device will have no effect. The next device connected to the system is a cooling device from group AHU. The cooling device consists of cooling coils and an associated cooling mechanism WO 98/57239 PCT/US98/11843 - 24 controlled by an associated device controller. The device controller turns the cooling coil on or off based on data of type 2 which is expects to receive on the bus. When the cooling device is connected to the bus, and has obtained a unique address, the lamp device and the temperature control device do not request data from the 5 cooling device since these devices are not in group AHU. The cooling device will request each device in group AHU to identify itself, since it requires data of type 2. Each of the devices in group AHU will respond to this request; in this case only the temperature control device will all respond. The temperature control device is consequently entered in the cooling device's group 10 member list as a member of group AHU. The cooling device thereafter sends a request for data of type 2 to the temperature control device. The temperature control device will respond to the request, and enter in its bind control table that this data is requested by the cooling device. It will also send a response to the cooling device, which will place the temperature control device in its bind control table, indicating that it should supply 15 data of type 2 to the cooling device. The cooling device does not require any external information to operate, and thus will not make any requests from other devices in its group for data. With the cooling device active in the system, commands from the temperature control device now causes changes in the temperature of the system. 20 Next, the lamp device of group RM2 is added to the system. The lamp device of group RM2 is internally identical to the lamp device of group RM1. Initially, the lamp device of group RM2 is assigned a unique address. Since this device requires data of type 1, it sends a request for this data once it has identified members of its associated group, RM2. Since no other devices which are part of group RM2 have been added to 25 the system, the lamp device from group RM2 will conclude that it is alone on the system, in its group. It will consequently not request switch data from the switch in group RM1 because this device did not respond when the lamp device from group RM2 requested group members. Once the switch device from group RM2 is added to the system however, its group assignment will be recognized by the lamp device in group 30 RM2, and the lamp device will thereafter store the address of the light switch device in group RM2 in its memory component, as the source of data of type 1. When this occurs the lamp device in group RM2 will actively control the lamp device.

WO 98/57239 PCT/US98/11843 -25 As each remaining new device is connected to the system, a similar process would occur for each new device, depending on whether it was to send, receive, or both send and receive data to or from other devices in the system. The further devices including the damper device unit, blower device, heating device, air exchange device, 5 and duplicate devices from RM2 would each connect to the system and self-configure in a similar manner to the devices above. The damper device would request data of type 6, indicating the percentage it should be open. The heating device would request data of type 3, indicating whether it should be on or off. The blower device would request data of type 4 indicating at what speed it should operate. The air exchange would request 10 data of type 5 indicating the percentage it should be open. The damper device, blower device, and air exchange device will also provide data of type 11, 9 and 10 about the percentage they are currently open, respectively, which would be used by the temperature control device. Relevant sections of the code used to implement this embodiment follows the 15 text of this specification. The foregoing descriptions of specific embodiments of the present invention are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, obviously many modification and variations are possible in view of the above teachings. It is intended 20 that the scope of the invention be defined by the following claims and their equivalents.

I

II slfbnd.h - Neuron C code for self binding devices 25 // #include <addrdefs.h> #include <msg_addr.h> #include <access.h> #include <string.h> 30 #include <SNVT CFG.h> #include "GroupNV.h" //increase the number of comm buffers 35 WO 98/57239 PCT/US98/11843 - 26 #define SLFMSGREQ_GROUP I // Broadcast message requesting other nodes within the same group #define SLFMSG_RSPGROUP 2 // direct message back to requestor 5 #define SLFMSG_GETGROUPS 3 // request for SBControl Variable data #define SLFMSG_SETGROUPS 4 // modify SBControl Variable data #define SLFMSG REQBIND 6 //direct message to initiate a bind sequence #define SLFMSG_RSPBIND 7 //response to bind initiation message 10 #define SLFMSGREQ_ADDR 10 //Broadcast Address Synchronization #define SLFMSG RSP_ADDR 11 //Broadcast Address Synchronization // definitions used for self binding 15 #define SLFBND MSGCODE 0x30 #define SLFBND MAGIC 97 #define MAX GROUP NAMES 2 #define SIZE GROUP NAME 9 20 #define SIZE VAR NAME 9 typedef unsigned GROUP NAME[SIZE_GROUP_NAME]; 25 ////////////////////////////////////////////////////////////////////////////////// 30 // message structures //All message used for self binding in Echelon use the Echelon Message type //"0x30". two message broadcast into the zero domain (REQUEST ADDRESS and REQUESTGROUP) //the remaining messages are direct using neuron id addressing. 35 //message structure for request bind WO 98/57239 PCT/US98/11843 - 27 typedef struct req_binddata { unsigned long rbvarid; } reqbinddata; 5 // message structure for respond bind typedef struct rsp binddata { unsigned long rbvarid; unsigned rb_gpid; 10 unsigned rb_gpmember; unsigned rb_gpsize; } rsp binddata; 15 typedef struct slf_address { unsigned slfa_flag; //This is a negotiation message unsigned slfa attempt; //attempt sequence number unsigned slfa_domlen; // domain length 20 unsigned[6] slfa domain; / unsigned slfahighsubnet; //current highest subnet# unsigned slfa_highnode; //current highest node # unsigned slfa_high_group; // highest current group assignment } slf_address_data; 25 #define NEWHIGH 0 #define TRYHIGH 1 #define IAMHIGH 2 30 //Self Binding message structure for data section of message // Self Binding message structure for data section of message 35 typedefstruct slfbnd_data { int sbmsg_magic; // contains predefined identifier for ALL self bind messages int sbmsg type; // message type unsigned sbmsg_nid[NEURON ID LEN]; // sender neuron id WO 98/57239 PCT/US98/11843 -28 unsigned sbmsg_subnet; unsigned sbmsgnode; GROUP_NAME sbmsggroupname; union { 5 reqbind_data rqbdata; rsp_bind_data rsbdata; slf_address_data adrdata; SBControl sbcdata; } sbmsg data; 10 } slfbnddata; 15////////////////////////////////////////////////////////////////////////////////// /5 // Self Binding Data structures

/

20 // Self Binding Variables control table ( held in flash) typedef struct ROLEDATA { unsigned rd function: 5; // function selector for this node unsigned long rd_varid; //variable identifier 25 unsigned rd source: 2; //internal, external or either unsigned rddefault: 2; //default when not available unsigned rdmultiple: 4; //action identifier if multiple sources detected long rddefaultval; // if the default is setvalue unsigned rd_nvidx; //NV index 30 unsigned rd_numref; //number of external references to this variable unsigned rdgroup; // group id for one-to many unsigned rdbndidx; //index to bind control table } ROLEDATA; 35 //defines for rd default: #define NODEFAULT 0 #define SETVALUE 1 WO 98/57239 PCT/US98/11843 - 29 // defines for rd source #define INTERNAL 0 #define EXTERNAL 1 #define EITHER2 5 // defines for rdtype #define ANAIN 0 #define DIGIN 1 #define ANAOUT 2 10 #define DIGOUT 3 #define PSEUDO 4 //defines for rdmultiple #define NOMULTIPLE 0 15 #define AVGMULTIPLE 1 #define SUMMULTIPLE 2 #define MINMULTIPLE 3 #define MAXMULTIPLE 4 #define LSTMULTIPLE 5 20 // Device Bind Control Table (In Flash) typedef struct BINDCONTROL { 25 unsigned long bc_varid; //variable identifier unsigned bc_roleidx; //index to configuration table unsigned bc_subnet; //subnet of bound NV unsigned bc_node; //node address of bound NV unsigned bcaddr[NEURON IDLEN]; //device address for bound NV 30 unsigned bc_gname; //index to group bound to unsigned bcnext; //index to next bind entry for this variable } BINDCONTROL; 35 //defines for bc direction #define INPUT BIND 0 #define OUTPUT BIND 1 // defines for bctype WO 98/57239 PCT/US98/11843 - 30 #define RFR BIND 0 #define RFR APPL 1 // defines for bc bind 5 #define SINGLE BIND 0 #define GROUP BIND 1 #define TOALL 1 #define TOONE 2 10 #define NULL 0 // Structure holds references to other devices in our group(s) 15 #define MAX GROUPLIST 30 typedef struct GROUPLIST { int gl_gname; //index to group name unsigned gladdr[NEURON ID LEN]; //device address 20 unsigned glsubnet: 7; unsigned glcurrent: 1; //indicates that binding is complete unsigned glnode; } GROUPLIST; 25 #define BINDSTATE START 0 #define BINDSTATE ADDR 1 30 #define BINDSTATE INIT 2 #define BINDSTATE RECFG 3 #define BINDSTATE NORMAL 4 #define BINDSTATE DISABLED 5 35 #define NORMAL CYCLE 5 #define ADDRESS CYCLE 5 // The following variables should be stored in flash or EEPROM in the future

//

WO 98/57239 PCT/US98/11843 -31 far offchip eeprom GROUP_NAME GroupName[MAXGROUP_NAMES]; far offchip eeprom BINDCONTROL bndcfg[MAX_BINDCONTROL]; far offchip eeprom boolean NeedData = FALSE; far offchip eeprom boolean GoodRole = FALSE; 5 far offchip eeprom GROUPLIST grplst[MAX_GROUPLIST]; extern far offchip eeprom int ROLEENTRIES; extern far offchip eeprom ROLEDATA slfcfg[]; // Global RAM Variables 10 unsigned CurState = BINDSTATE_DISABLED; // binder state unsigned WaitingForAddress = 0; int CURGLIDX = 0; //index of the current item in the grouplist being processed 15 int CURSLFIDX = 0; //index of the current item in the grouplist being processed unsigned MySubnet = 0; unsigned MyNode = 0; unsigned HighSubnet = 0; 20 unsigned HighNode = 0; unsigned HighGroup = 0; unsigned long CurSeqld = 0; long DistanceFromHigh = 32767; 25 // Timers stimer repeating BndCtrl; // Bind Control Timer // Selfbinding message tag msg tag bind info(nonbind) TAG_OUT; 30 // Self Bind Configuration Input Network Variable (defined in GroupNV.h) // network input sd string ("SB Control") SBControl nviSBControl = {0,0,""; 35 config network input sd string ("SB Config") SNVTconfig_src nciSBConfig = CFG_LOCAL; II

/

WO 98/57239 PCT/US98/11843 - 32 // START OF SELF BINDING CODE

/

// utility version of strcpy (no return value) 5 void CopyGroup(unsigned *ostr,const unsigned *istr) { int i; for(i = 0; i < SIZE_GROUP_NAME ;i++) 10 { ostr[i] = istr[i]; } return; } 15 //utility version of strncmp boolean Compare(const unsigned *ostr,const unsigned *istr,int sz) { int i; 20 for(i= 0; i < sz;i++) { if(ostr[i] =='\0') if (istr[i) =='\0') return TRUE; 25 else return FALSE; if(ostr[i] != istr[i])return FALSE; } return TRUE; 30 } // SendSLFMsg0 - Send a self bind application message 35 // // inputs - Pointer to Self Bind message data block // destination type // destination neuron id

//

WO 98/57239 PCT/US98/11843 -33 // outputs - none

/

void SendSLFMsg(slfbnd_data *slfinsg,int dest,const unsigned *destnid,int gname idx) { 5 watchdog_update(); //don't let the watchdog expire msg_out.tag = TAGOUT; msg_out.code = SLFBND_MSGCODE; msg_out.authenticated = FALSE; 10 msg_out.service =UNACKD; slfmsg->sbmsg magic = SLFBND_MAGIC; slfmsg->sbmsg subnet = MySubnet; slfmsg->sbmsg_node = MyNode; memcpy(slfmsg->sbmsg_nid,read_only_data.neuron_id,NEURON_ID_LEN); 15 if(gname idx !=-1) CopyGroup(slfmnsg->sbmsggroupname,GroupName[gname idx]); else memset(slfmsg->sbmsggroupname,0,SIZE_GROUP NAME); memcpy(msg_out.data, slfmsg, sizeof(slfbnd data)); 20 if(dest = TOALL) { msg_out.destaddr.bcast.type = BROADCAST; msg out.dest_addr.bcast.domain= 1; msg out.dest_addr.bcast.subnet = 0; 25 } else {//send message to a specific neuron id msg_out.destaddr.nrnid.type = NEURONID; memcpy(msgout.dest_addr.nnid.nid,destnid,NEURON ID LEN); 30 } msgsend(; if(CurState == BINDSTATE_NORMAL) BndCtrl = NORMAL_CYCLE; // reset the cycle timer if running normally 35 return;

}

WO 98/57239 PCT/US98/11843 - 34 // SendHighAddresso - Send a message containing the current high address 5 // // inputs - contents of the message

/

// outputs -none

/

10 // void SendHighAddress(int flag,int dest,unsigned *destnid, unsigned xSubnet, unsigned xNode,unsigned long xSeq,unsigned xGroup) 15 { slfbnd_data slfmsg; memset(&slfmsg,0,sizeof(slfbnd_data)); slfmsg.sbmsg type = SLFMSG_RSPADDR; 20 slfmsg.sbmsg data.adrdata.slfaflag = flag; slfmsg.sbmsg data.adrdata.slfa_attempt = 0; slfmsg.sbmsg_data.adrdata.slfa seq = xSeq; slfmnsg.sbmsg_data.adrdata.slfa high_subnet = xSubnet; slfmsg.sbmsg data.adrdata.slfa high_node = xNode; 25 slfmsg.sbmsg_data.adrdata.slfahigh group = xGroup; SendSLFMsg(&slfmsg,dest,destnid,- 1); return; } 30 ///////////////////////////////////////////////////////////////////////////////////// // Self Bind Message Generation routines

/

35 //////////////////////////////////////////////////////////////////////////////////// // SendGroupRequestMessage( - Ask for all other devices in the same group to identify WO 98/57239 PCT/US98/11843 -35 // themselves. This message is only generated if this device // requires external information in oreder to perform the 5 // selected application.

/

void SendGroupRequestMessageo { int i; 10 slfbnddata slfmtsg; // self binding message structure slfmsg.sbmsg type = SLFMSG_REQ_GROUP; i= 0; while(GroupName[i][0] != '\0') 15 { SendSLFMsg(&slfmsg,TOALL,NULL,i); i++; } } 20 ////////////////////////////////////////////////////////////////////////////////////// II // CheckGroupNameo - Check a group name

/

25 // inputs - Pointer to group name to check

/

// outputs -TRUE if name matches // FALSE if no match // 30 int CheckGroupName(GROUP_NAME grname) { int i; for(i= 0; i < MAX_GROUP_NAMES; i++) { 35 if(Compare(grname,&GroupName[i][0],8))return(i); } return(- 1);

}

WO 98/57239 PCT/US98/11843 - 36 // CheckNewGroupNameO - See if the group name has changed and take the // appropriate action(s)l. 5 // // inputs - none

/

// outputs -none

/

10 void CheckNewGroupNameo { int ij,k; char ch; 15 if(!nviSBControl.SBActive) //If self bind is not active - forget it. return; // check for a valid role NeedData = FALSE; 20 GoodRole = FALSE; for(i = 0; i < ROLEENTRIES;i++) { if((!slfcfg[i].rd_function) 1 (slfcfg[i].rdfunction == nviSBControl.SBRole)) { 25 GoodRole = TRUE; //role number is valid if(slfcfg[i].rd source == EXTERNAL || slfcfg[i].rd source== EITHER) { NeedData = TRUE; // we need external data break; // don't need to 30 scan any more!! } } 35 if(!GoodRole) return; //didn't find the role // role is valid - parse the group name(s) i = 0; WO 98/57239 PCT/US98/11843 -37 j=0; k =0; while((ch = nviSBControl.SBGroup[i]) != '\0') { 5 if(j == MAX GROUP_NAMES) return; //too many semicolons if(ch == ';') { GroupName[j][k] = '\0'; // nul terminate the groupname k = 0; 10 j++; } else { GroupName[j][k] = ch; // copy the character 15 k++; if(k > 8) //to many characters in the group name { GroupName[j][k-1] ='\0'; // nul terminate the groupname return; 20 } } i++; } GroupName[j][k] ='\0'; // nul terminate the groupname 25 // here's where we start the whole thing going!! // Request id from other devices in our group(s) SendGroupRequestMessageo; 30 return; } 35 ////////////////////////////////////////////////////////////////////////////////////// 35 // ClearBindConfigo - Clear all of the binding information!! // - This is a brute force re-init of the self binder. current use is WO 98/57239 PCT/US98/11843 -38 // to reset the device for testing purposes. For actual production use // see the TODO comments.

/

// 5 // inputs - none

/

// outputs -none // 10 void ClearBindConfigo { domainstruct dentry; address_struct adentry; nvstruct nventry; 15 int i,k; //clear the domain table dentry = *(access_domain(l)); dentry.len = OxFF; 20 dentry.id[0] = 0; dentry.subnet = 0; dentry.node = 0; for(i = 0; i < AUTH_KEY_LEN; i++)dentry.key[i] = 0xFF; update domain(&dentry,0); 25 //update domain(&dentry, 1); //reset the bind control tables for(i= 0; i <MAX_BINDCONTROL; i++) { 30 //TODO send a message to the other node for each bind to terminate the bind bndcfg[i].bcroleidx = -1; // clear the bind control table bndcfg[i].bc_next = -1; //clear the bind control table I for(i =0; i < ROLEENTRIES;i++) 35 { slfcfg[i].rd_numref = 0; slfcfg[i].rd_group = 0; slfcfg[i].rd bndidx = -1;

I

WO 98/57239 PCT/US98/11843 -39 for(i = 0; i < MAX_GROUPLIST;i++) { grplst[i].gl_gname = -1; grplst[i].gl_subnet = 0; 5 } watchdog update(); // most of this is happening in flash //takes a long 10 time //clear the NV tables k = readonly_data.nv_count; for(i= 0;i <k; i++) 15 { nventry = *(accessnv(i)); nventry.nv_selector_hi = Ox3F; nventry.nv_selectorlo = OxFF - i; nventry.nv_addrindex = Ox0F; // No address index 20 update_nv(&nventry,i); } // clear the address table 25 for(i 0; i < 15;i++) { //adentry = *(access_address(i)); // don't need to do this (yet) adentry.sn.type = UNBOUND; adentry.sn.domain = 0; 30 adentry.sn.node = 0; adentry.sn.rpt_timer = 14; // 2 second repeat adentry.sn.retry = 4; // 4 retries adentry.sn.txtimer = 12; // 1 second timeout for ackd adentry.sn.subnet = 0; 35 update address(&adentry,i); } return;

}

WO 98/57239 PCT/US98/11843 - 40 void CheckGRList(unsigned gname_idx,unsigned *nid,unsigned subnet,unsigned node) { int i,j, spareentry; 5 // add this device to the list of devices if not already there spareentry = -1; for(i = 0; i < MAX GROUPLIST;i++) { if((grplst[i].gl_gname == -1) && (spareentry == -1))spareentry = i; //save in case 10 we have to add it // check the group name and the neuron id!! if((grplst[i].gl gname == gname idx) && (Compare(nid,grplst[i].gl_addr,6))) { 15 // entry already exists - new device message occurs on reset, set up for a refresh sequence grplst[i].gl_current = FALSE; } } 20 if(i== MAX_GROUPLIST) //no existing entry for this device { //add an entry grplst[spareentry].gl_gname = gnameidx; //eeprom_memcpy(&grplst[spareentry].gl_addr[0],&nid[0],6); 25 for(j = 0; j < 6;j++)grplst[spareentry].gl_addr[j] = nid[j]; grplst[spareentry].gl_subnet = subnet; grplst[spareentry].gl_node = node; grplst[spareentry].gl_current = FALSE; } 30 return; } 35 // BINDER STATE MACHINE // H/

//////////////////////////////////////////////////////////////////////////////////

WO 98/57239 PCT/US98/11843 -41 // EnterStateo - Switch the binder state machine to a new mode of operation

/

// inputs - state number to enter // 5 // outputs -none

/

void EnterState(int newstate) 10 { switch(newstate) { case BINDSTATE START: BndCtrl = 1; //Start the Bind Control 15 State Machine CurState = BINDSTATESTART; break; case BINDSTATE ADDR: // Obtain a unique subnet and node id within 20 //the Self Bind Domain WaitingForAddress = 1; CurState = B1NDSTATEADDR; break; 25 case BINDSTATEINIT: //Initialize self binding data CurState = BINDSTATEINIT; break; case BINDSTATE RECFG: //Re-initialize 30 self binding data after error CurState = BINDSTATERECFG; break; case BINDSTATE NORMAL: //Normal binder operation 35 BndCtrl = NORMAL_CYCLE; // switch to 5 second cycle CurState = BINDSTATE_NORMAL; break; case B1INDSTATE DISABLED: WO 98/57239 PCT/US98/11843 - 42 BndCtrl = 0; // Stop the Bind Control State Machine CurState = BINDSTATE DISABLED; break; 5 default: break; } } 10 // // CheckSelfBind() - Self bind configuration may have changed

/

// inputs - none

/

15 // outputs -none

/

/

void CheckSelfBind() { 20 if((nviSBControl.SBActive == 0)II(nciSBConfig != CFG_LOCAL)) //Not active - do we have to clean up? { if(CurState != BINDSTATEDISABLED) // we were active - reset the bind tables 25 { timers_off(); ClearBindConfigo; EnterState(BINDSTATE_DISABLED); } 30 else { if((nviSBControl.SBActive)&&(nciSBConfig== CFG_LOCAL)) { 35 EnterState(BINDSTATE_START); } } return;

}

WO 98/57239 PCT/US98/11843 -43 // Self Bind Message Handler routines 5 // void PrcMsgReqGroup(slfbnddata *inmsg,int gname_idx) { 10 // A device is asking who else is in it's group slfbnddata slfmsg; // self binding message structure CheckGRList(gname idx,inmsg->sbmsgnid,inmsg->sbmsg_subnet,inmsg->sbmsgnode); memset(&slfmsg,0,sizeof(slfbnd_data)); 15 slfmsg.sbmsg type = SLFMSGRSPGROUP; SendSLFMsg(&slfmsg,TOONE,inmsg->sbmsgnid,gname_idx); } 20 void PrcMsgRspGroup(slfbnd_data *inmsg,int gname idx) { // A device is telling us that it is in the same group as us if(gname idx !=-1) 25 { CheckGRList(gname_idx,inmsg->sbmsg nid,inmsg->sbmsg_subnet,inmsg->sbmsgnode); } } 30 30 ////////////////////////////////////////////////////////////////////////////////// // PrcMsgGroupsO - process message setting or getting group names

/

35 // inputs - pointer to bind request message // // outputs -none

//

WO 98/57239 PCT/US98/11843 - 44 void PrcMsgGroups(slfbnddata *inmsg) { slfbnd data slfmnsg; // self binding message structure unsigned neuronid[NEURON IDLEN]; 5 intj; memcpy(&slfmnsg,inmsg,sizeof(slfbnddata)); if(inmsg->sbmsg type == SLFMSGGET_GROUPS) 10 { memcpy(&slfmisg.sbmsg_data.sbcdata, &nviSBControl, sizeof(SBControl)); } else { 15 nviSBControl.SBActive = slfmsg.sbmsg_data.sbcdata.SBActive; nviSBControl.SBRole = slfmsg.sbmsg_data.sbcdata.SBRole; for( = 0; j < 26; j++) nviSBControl.SBGroup[j] = slfmsg.sbmsg_data.sbcdata.SBGroup[j]; } 20 SendSLFMsg(&slfmsg,TOALL,inmsg->sbmsg nid,- 1); if(inmsg->sbmsg type == SLFMSG_SET_GROUPS) CheckSelfBind(); return; 25 } // SendBindResponseo - Send a response to a bind request 30 // // inputs - pointer to bind request message // index to the self bind configuration table entry // index to the self bind control table entry // 35 // outputs -none void SendBindResponse(int bndidx,int slfidx,int gnameidx) { slfbnddata slfmisg; // self binding message structure WO 98/57239 PCT/US98/11843 -45 unsigned neuronid[NEURON IDLEN]; intj; memset(&slfmnsg,0,sizeof(slfbnd data)); 5 slfmnsg.sbmsg type = SLFMSG_RSPBIND; slfmsg.sbmsg_data.rsbdata.rb_varid = slfcfg[slfidx].rdvarid; slfmsg.sbmsg_data.rsbdata.rb_gpid = slfcfg[slfidx].rd_group; if(! slfcfg[slfidx].rdgroup) slfmtsg.sbmsg_data.rsbdata.rbgpmember = 0; // not a group bind 10 else slfmsg.sbmsg data.rsbdata.rbgpmember = slfcfg[slfidx].rdnumref + 1; slfmsg.sbmsgdata.rsbdata.rbgpsize = 0; // set for unlimited size group in destinations for(j = 0; j < NEURON ID LEN; j++) 15 neuronid[j] = bndcfg[bndidx].bc addr[j]; SendSLFMsg(&slfmsg,TOONE,neuronid,gnameidx); return; } 20 // SetupGroupBindo - Setup the internal tables for a group binding 25 // // inputs - pointer to bind request message // index to the self bind configuration table entry

/

// outputs -none 30 // void SetupGroupBind(int slfidx,int bndidx,slfbnd data *inmsg,int gname idx) { address_struct adentry; nv_struct nventry; 35 int i,j,k; long tmpsel; nventry = *(access nv(slfcfg[slfidx].rd nvidx)); WO 98/57239 PCT/US98/11843 -46 //is the variable already in a group bind? // if not, then convert the bind to a group bind // else just bind the variable to the next device. if(!slfcfg[slfidx].rd_group) //not in a group bind 5 { // increment the high group HighGroup++; // Broadcast a new high address message (informs all other devices of the new high group) SendHighAddress(NEWHIGH,TOALL,NULL, HighSubnet,HighNode,CurSeqld,HighGroup); 10 slfcfg[slfidx].rdgroup = HighGroup; // Current binding must be restructured as a group bind // TODO examine the address and NV tables to determine if the existing address entry could be // re-used for the group bind. 15 // TODO An existing group could be re-used with different selector id's // (how this can be accomplished needs to be examined) // find a free entry in the address table for(i = 0; i < 15;i++) { 20 adentry = *(access_address(i)); if(adentry.sn.type == UNBOUND) // Unused entry { adentry.gp.type = 1; // high bit in type indicates group adentry.gp.size = 0; // unlimited size group 25 adentry.gp.domain = 0; adentry.gp.member 0; adentry.gp.rpt_timer = 14; //2 second repeat adentry.gp.retry = 4; // 4 retries adentry.gp.tx_timer = 12; //1 second timeout for ackd 30 adentry.gp.group = slfcfg[slfidx].rd group; update address(&adentry,i); break; } 35 if(i == 15) return; // no entries in the address table - forget it!! // TODO take some remedial action!! // update the NV table WO 98/57239 PCT/US98/11843 - 47 tmpsel= slfcfg[slfidx].rdvarid & Ox3FFF; nventry.nv_selector lo = (tmpsel & Oxff); nventry.nv_selector hi = (tmpsel >> 8); nventry.nv_addr index = i; 5 updatenv(&nventry,slfcfg[slfidx].rd nvidx); SendBindResponse(slfcfg[slfidx].rd_bndidx,slfidx,gnameidx); // modify the binding in the first destination } 10 // Update the binder control table bndcfg[bndidx].bc_varid = slfcfg[slfidx].rd_varid; bndcfg[bndidx].bc_roleidx = slfidx; bndcfg[bndidx].bc_subnet = inmsg->sbmsgsubnet; 15 bndcfg[bndidx].bc_node = inmsg->sbmsg node; for(j = 0; j < NEURONID LEN; j++) bndcfg[bndidx].bc addr[j]= inmsg->sbmsg nid[j]; bndcfg[bndidx].bc_gname = gnameidx; bndcfg[bndidx].bc_next = slfcfg[slfidx].rd_bndidx; //insert this entry at the 20 beginning of the list slfcfg[slfidx].rd_numref++; slfcfg[slfidx].rd_bndidx = bndidx; // Send the bind response!! SendBindResponse(bndidx,slfidx,gname_idx); 25 return; } 30 // // SetupNodeBindO - Setup the internal tables for a subnet/node binding

/

// inputs - pointer to bind request message // index to the self bind configuration table entry 35 // // outputs -none // void SetupNodeBind(int slfidx,int bndidx,slfbnd_data *inmsg,int gnameidx)

{

WO 98/57239 PCT/US98/11843 -48 address_struct adentry; nvstruct nventry; int i,j; long tmpsel; 5 // find a free entry in the address table for(i= 0; i < 15;i++) { 10 adentry = *(access_address(i)); if(adentry.sn.type == UNBOUND) //Unused entry { adentry.sn.type = SUBNET_NODE; adentry.sn.domain = 0; 15 adentry.sn.node = inmsg->sbmsg_node; adentry.sn.rpttimer = 14; // 2 second repeat adentry.sn.retry = 4; // 4 retries adentry.sn.tx_timer = 12; //1 second timeout for ackd adentry.sn.subnet = inmsg->sbmsgsubnet; 20 updateaddress(&adentry,i); break; } if((adentry.sn.type == SUBNET NODE) && (adentry.sn.domain == 0) 25 && (adentry.sn.node == inmsg->sbmsg node) && (adentry.sn.subnet == inmsg->sbmsgsubnet)) { break; //found an existing entry for this device!! } 30 } if(i== 15) return; //ignore the message - bind will not happen until a positive // response is sent. No Spare entries!! //Should possibly raise an alarm at this 35 point!! // update the NV table // idx points to entry in the self bind control table WO 98/57239 PCT/US98/11843 -49 nventry = *(accessnv(slfcfg[slfidx].rd nvidx)); tmpsel= slfcfg[slfidx].rd varid & Ox3FFF; nventry.nv_selectorlo = (tmpsel & Oxff); nventry.nv_selectorhi = (tmpsel >> 8); 5 nventry.nv_addr index = i; updatenv(&nventry,slfcfg[slfidx].rdnvidx); // Update the binder control table bndcfg[bndidx].bcvarid = slfcfg[slfidx].rd_varid; 10 bndcfg[bndidx].bc roleidx = slfidx; bndcfg[bndidx].bc_subnet inmsg->sbmsg_subnet; bndcfg[bndidx].bcnode = inmsg->sbmsg_node; for(j = 0; j < NEURON ID LEN; j++) bndcfg[bndidx].bc_addr[j]= inmsg->sbmsgnid[j]; 15 bndcfg[bndidx].bc_gname = gname idx; bndcfg[bndidx].bcnext = slfcfg[slfidx].rd bndidx; slfcfg[slfidx].rd_bndidx = bndidx; slfcfg[slfidx].rd_numref++; SendBindResponse(bndidx,slfidx,gnameidx); 20 return; } ////////////////////////////////////////////////////////////////////////////////// 25 25 //////////////////////////////////////////////////////////////////////////////////

/

// PrcMsgReqBndO - Process a request to bind one of our output variables

/

// inputs - pointer to bind request message 30 // // outputs -none

/

void PrcMsgReqBnd(slfbnd_data *inmsg,int gname idx) 35 { int i,k; // Scan the bind control table to see if we have it. // May be redundant - the other device wouldn't have requested the bind if we didn't have it WO 98/57239 PCT/US98/11843 - 50 for(i = 0; i < ROLEENTRIES;i++) { if(((!slfcfg[i].rd_function) II (slfcfg[i].rd function == nviSBControl.SBRole)) && (inmsg->sbmsg data.rqbdata.rbvarid == slfcfg[i].rdvarid) 5 && (slfcfg[i].rd_source != EXTERNAL)) // EITHER or INTERNAL allowed { //Is there an existing entry for this device ? k = slfcfg[i].rd_bndidx; while(k != -1) 10 { if((bndcfg[k].bc subnet == inmsg->sbmsgsubnet) && (bndcfg[k].bc_node == inmsg->sbmsgnode)) { //a bind to this device already exists - send a bind response; 15 SendBindResponse(k,i,gname_idx); //existing entry for this NV!! return; } k = bndcfg[k].bcnext; 20 } //If we get here, this is a new device requesting the bind for this variable //Get a spare entry from the bind control table for(k = 0; k < MAX_BINDCONTROL; k++) 25 { if(bndcfg[k].bcroleidx == -1) //found a spare entry { if(slfcfg[i].rd numref == 0) { 30 SetupNodeBind(i,k,inmsg,gname idx); // Not bound - set up a one-to-one bind } else { 35 SetupGroupBind(i,k,inmsg,gnameidx); // Setup a group bind } break;

}

WO 98/57239 PCT/US98/11843 -51 } break; //terminate the loop } } 5 } // PrcMsgRspBndo - Process a response to bind a variables 10 // // inputs - pointer to bind response message

/

// outputs -none

/

15 // void PrcMsgRspBnd(slfbnd_data *inmsg,int gnameidx) { nv_struct nventry; addressstruct adentry; 20 int ij,k,1; long tmpsel; // Scan the bind control table to see if we need it. for(i = 0; i < ROLEENTRIES;i++) 25 { if(((!slfcfg[i].rd_function) || (slfcfg[i].rd_function == nviSBControl.SBRole)) && (slfcfg[i].rdsource == EXTERNAL) && (inmsg->sbmsg_data.rsbdata.rbvarid == slfcfg[i].rdvarid)) { 30 // Has this binding already been made? k = slfcfg[i].rdbndidx; // scan the dynamic binder control table for this entry while(k !=-1) { 35 if((bndcfg[k].bc_subnet == inmsg->sbmsg_subnet) && (bndcfg[k].bc_node == inmsg->sbmsgnode)) { //entry already exists!! break; WO 98/57239 PCT/US98/11843 - 52 } k = bndcfg[k].bc next; } if(k == -1) 5 { // find a spare entry in the dynamic binder control table for(k =0; k < MAXBINDCONTROL; k++) { if(bndcfg[k].bc_roleidx == -1) // found a spare entry 10 { // Update the binder control table bndcfg[k].bc_varid = slfcfg[i].rdvarid; bndcfg[k].bcroleidx = i; bndcfg[k].bc subnet = inmsg->sbmsg_subnet; 15 bndcfg[k].bc node = inmsg->sbmsgnode; for(j = 0; j < NEURON ID LEN; j++) bndcfg[k].bc addr[j] = inmsg->sbmsgnid[j]; bndcfg[k].bc_gname = gname_idx; // set up the link info 20 slfcfg[i].rd_numref++; bndcfg[k].bc next = slfcfg[i].rd_bndidx; slfcfg[i].rdbndidx =k; break; } 25 } } if(k == MAX BINDCONTROL)return; //no spare entries nventry = *(accessnv(slfcfg[i].rdnvidx)); //Is this a group bind?? 30 if(inmsg->sbmsgdata.rsbdata.rb_gpmember) { if(slfcfg[i].rd_group == 0)// only do this the first time { slfcfg[i].rd_group = inmsg->sbmsgdata.rsbdata.rbgpid; 35 //we need to make an entry in the address table for the group for(l = 0; 1 < 15;1++) { adentry = *(access_address(l)); WO 98/57239 PCT/US98/11843 - 53 if(adentry.sn.type == UNBOUND) // Unused entry { adentry.gp.type = 1; //high 5 bit in type indicates group adentry.gp.size = 0; //this one plus two others adentry.gp.domain = 0; adentry.gp.member = 0; 10 adentry.gp.rpt_timer = 14; // 2 second repeat adentry.gp.retry = 4; //4 retries adentry.gp.tx_timer = 12; //1 second 15 timeout for ackd adentry.gp.group = inmsg >sbmsg_data.rsbdata.rb_gpid; update_address(&adentry,1); nventry.nv_addrindex = I; //entry 20 in the address table required for group bind break; } } if(i == 15) return; //no entries in the 25 address table - forget it!! } } //update the NV table tmpsel = slfcfg[i].rd_varid & 0x3FFF; 30 nventry.nv_selector lo = (tmpsel & Oxff); nventry.nv_selector hi= (tmpsel >> 8); updatenv(&nventry,slfcfg[i].rdnvidx); break; // terminate the loop } 35 }

}

WO 98/57239 PCT/US98/11843 - 54

/

// PrcMsgReqAddr() - Process a message requesting the current high address

/

// inputs - Pointer to the request message 5 // // outputs -none

/

// comments - This device responds if the number of retries indicated in the message 10 // is greater than its difference from the high address. (if known) // void PrcMsgReqAddr(slfbnddata *inmsg) 15 { if((CurState!= BINDSTATE_START) && (CurState!= BINDSTATEADDR)) { if(inmsg->sbmsg_data.adrdata.slfaattempt > DistanceFromHigh) {// respond to the request 20 SendHighAddress(NEWHIGH,TOONE,inmsg->sbmsg_nid, HighSubnet,HighNode,CurSeqld,HighGroup); } } return; 25 } // PrcMsgRspAddr() - Process a message containing the current high address 30 // // inputs - Pointer to the response message

/

// outputs -none 35 // void PrcMsgRspAddr(slfbnd data *inmsg) { unsigned xSubnet; WO 98/57239 PCT/US98/11843 - 55 unsigned xNode; unsigned long xSeq; // We need to do some checking here to determine if there are any conflicts. // e.g. did we receive more than one reply? 5 // did we receive different sequence id's? if(inmsg->sbmsg_data.adrdata.slfaflag == NEWHIGH) { xSubnet = inmsg->sbmsg_data.adrdata.slfa high_subnet; 10 xNode = inmsg->sbmsg_data.adrdata.slfa highnode; xSeq = inmsg->sbmsg_data.adrdata.slfa seq; if(WaitingForAddress || (xSeq == CurSeqld)) { if(((xSubnet == HighSubnet) && (xNode > HighNode)) | 15 (xSubnet > HighSubnet)) //We got a higher one { WaitingForAddress = 0; //reset the wiating for addresss flag (if set) HighGroup = inmsg->sbmsg data.adrdata.slfa_high_group; 20 HighSubnet = xSubnet; HighNode = xNode; CurSeqld = xSeq; DistanceFromHigh = ((HighSubnet-MySubnet)*256) + (HighNode MyNode); 25 } } else {// TODO: Broadcast an error indication that we have two parallel sequences //we'll figure out what to do with this later. 30 } 35 ////////////////////////////////////////////////////////////////////////////////// 35 // ProcessStartState0 - Perform any initialization required by the Binder

//

WO 98/57239 PCT/US98/11843 - 56 // inputs - none // outputs -none 5 // comments - State is entered at every start up of the device

/

void SetSBDomain() { domain_struct dentry; 10 unsigned i; //Check to see whether we already have a valid subnet and node dentry = *(access_domain(1)); // Second domain entry is zero length and used for Broadcasting within the domain 15 if(dentry.len == 0xFF) //Not in use - Put us in the self bind domain!! { dentry.subnet = 9; dentry.node = 9; dentry.len = 0; //0 length domain 20 for(i= 0; i < AUTH_KEY_LEN; i++) //no authentication!! (yet) dentry.key[i] = OxFF; update_clonedomain(&dentry,1); //inserts this device into "self binding domain" } return; 25 } void ProcessStartStateo { domain_struct dentry; 30 // Check to see whether we already have a valid subnet and node dentry = *(accessdomain(l)); // Second domain entry is zero length and used for Broadcasting within the domain MySubnet = 0; 35 MyNode = 0; if(dentry.len == OxFF) //Not in use - Self Binding NOT started yet - let's start it!! { ClearBindConfig(); // clear Network image and bind control stuff WO 98/57239 PCT/US98/11843 - 57 SetSBDomain(); EnterState(BINDSTATE_ADDR); // Enter address negotiation state } else 5 { if(dentry.len == 0) // already in the zero length domain { // check the valid address flag dentry = *(accessdomain(0)); //first domain entry is the actual 10 node address if((dentry.len ! = Oxff) && (dentry.subnet != 0) && (dentry.subnet != 0)) { //assume our current address is valid. MySubnet = dentry.subnet; MyNode = dentry.node; 15 EnterState(BINDSTATEINIT); //move to the next state } else { EnterState(BINDSTATEADDR); // Enter address 20 negotiation state } } } } 25 // ProcessAddressStateo - Ensure that we obtain a valid subnet / node 30 // address prior to any other processing.

/

// inputs - none // 35 // outputs -none /void ProcessAddressState void ProcessAddressState0 WO 98/57239 PCT/US98/11843 - 58 { domain struct dnew; unsigned i; slfbnd_data slfmsg; 5 // ask the highest address device if we can have the next address // Broadcast the request just in case some other device is temporarily handling //the requests. BndCtrl = ADDRESS_CYCLE; // 5 second cycle 10 if(WaitingForAddress) { if(WaitingForAddress > 10) //20 seconds - setup to use subnet 1 node 1 { HighSubnet = 1; 15 HighNode = 0; HighGroup = 0; //set the high group id to 0 CurSeqld = 0; for(i = 0; i <NEURON ID LEN; i++)CurSeqId = crc 1 6(CurSeqId,read_only data.neuron_id[i]); 20 } else { HighSubnet = 0; HighNode = 0; 25 // Broadcast an address request slfmsg.sbmsg type = SLFMSGREQ_ADDR; slfmsg.sbmsg data.adrdata.slfa attempt = WaitingForAddress++; SendSLFMsg(&slfmsg,TOALL,NULL,- 1); return; 30 } } II we got an address dnew = *(access_domain(0)); 35 HighNode++; if(HighNode > 110) //leave room for other devices within the subnet { HighSubnet++; WO 98/57239 PCT/US98/11843 - 59 HighNode = 1; } dnew.len = 1; dnew.id[0] = Ox01; 5 dnew.subnet = HighSubnet; dnew.node = HighNode; for(i = 0; i < AUTH_KEYLEN; i++)dnew.key[i] = OxFF; MySubnet = HighSubnet; MyNode = HighNode; 10 update domain(&dnew,0); DistanceFromHigh = 0; //we are the highest address Broadcast a "new high" message SendHighAddress(NEWHIGH,TOALL,NULL, HighSubnet,HighNode,CurSeqld,HighGroup); EnterState(BINDSTATE INIT); //Enter self bind initialization state 15 } // ProcesslnitStateo- Perform any required initialization after we have a 20 // valid address

/

// inputs - none // outputs -none 25 // void ProcessInitState( //Self Binder Initialization phase { 30 EnterState(BINDSTATE_NORMAL); CheckNewGroupName(); return; } 35 void ProcessNormalState() // Self Binder Normal Operation { //check the Group List to see if we have anything to do intj; WO 98/57239 PCT/US98/11843 - 60 slfbnddata slfmsg; // Any other housekeeping should be performed here. 5 if(NeedData) { for(; CURGLIDX < MAXGROUPLIST; CURGLIDX++) { if((!grplst[CURGLIDX].gl current)&& (grplst[CURGLIDX].gl_subnet != 0)) 10 { for(j = CURSLFIDX;j < ROLEENTRIESj++) { if((!slfcfg[j].rd function) (slfcfg[j].rd function== nviSBControl.SBRole)) 15 { if(slfcfg[j].rd source != INTERNAL) //this variable could come from elsewhere { //ask the device whether it can supply this variable 20 memset(&slfmsg,0,sizeof(slfbnddata)); slfmsg.sbmsg type = SLFMSG REQ BIND; slfmsg.sbmsg_data.rqbdata.rb varid = slfcfg[j].rd varid; 25 SendSLFMsg(&slfmsg,TOONE,grplst[CURGLIDX].gl_addr,grplst[CURGLIDX].gl_gname); CURSLFIDX = ++j; //set up for the next entry return; } 30 } } // check to see if we need to clean up these bindings for some reason // This entry in the device group list is fully processed grplst[CURGLIDX].gl_current = TRUE; 35 CURSLFIDX = 0; } } CURGLIDX = 0;

}

WO 98/57239 PCT/US98/11843 -61 return; } 5 5////////////////////////////////////////////////////////////////////////////////// // Binder timing loop

/

10 // inputs- none

/

// outputs -none

/

15 when(timer expires(BndCtrl)) { switch(CurState) { 20 case BINDSTATE START: ProcessStartStateo; //This occurs on power up or reset. break; case BINDSTATE ADDR: ProcessAddressStateo; //Address Negotiation phase 25 break; case BINDSTATE INIT: ProcesslnitStateo; //Self Binder Initialization phase break; case BINDSTATE_RECFG: // TODO: An address or sequence error was detected 30 reconfigure (later) break; case BINDSTATE_NORMAL:// TODO: Binder Normal State do some integrity checking ProcessNormalStateO; // Self Binder Initialization phase 35 break; default: break; }

}

WO 98/57239 PCT/US98/11843 - 62 // Incoming Message Handler 5 // when(msg_arrives(SLFBND_MSGCODE)) { slfbnd_data bndmsg; 10 int gname_idx; if(msg_in.len <= sizeof(slfbnddata)) //Is the message length correct? { memcpy(&bndmsg,&msg_in.data[0],sizeof(slfbnddata)); 15 if(bndmsg.sbmsg_magic == SLFBNDMAGIC) //check the magic number - bit of extra security!! { // see if we have the group name // first set of messages can be handled at any time. switch (bndmsg.sbmsg type) 20 { case SLFMSG_REQ ADDR: // Broadcast address arbitration message PrcMsgReqAddr(&bndmsg); break; 25 case SLFMSG RSP ADDR: // Broadcast address arbitration message PrcMsgRspAddr(&bndmsg); break; case SLFMSG_GET_GROUPS: //request for SBControl Variable 30 data case SLFMSG_SETGROUPS: // modify SBControl Variable data PrcMsgGroups(&bndmsg); break; 35 default: break; } if(CurState == BINDSTATE_NORMAL)

{

WO 98/57239 PCT/US98/11843 - 63 //These message can only be processed after initialization is complete gname_idx = CheckGroupName(bndmsg.sbmsg_groupname); if(gname idx ! -1) { 5 switch (bndmsg.sbmsg type) { case SLFMSG_REQ_GROUP: //Broadcast message requesting other nodes within the same group PrcMsgReqGroup(&bndmsg,gname_idx); 10 break; case SLFMSG RSP_GROUP: //direct message back to requestor PrcMsgRspGroup(&bndmsg,gname idx); break; 15 case SLFMSG REQ_BIND: //direct message to initiate a bind sequence PrcMsgReqBnd(&bndmsg,gname_idx); break; case SLFMSG_RSP_BIND: //response to bind 20 initiation message PrcMsgRspBnd(&bndmsg,gnameidx); break; default: break; 25 } } } } 30 msgfree(; // Throw away any other messages. 35 when(msgarrives) { msg free(;

}

WO 98/57239 PCT/US98/11843 - 64 void InitSelfBind() { // Should be called from the "when(reset)" event. 5 // // set up the plug and play domain in the second entry in the domain table // N.B. (TODO) Future versions should test the domain table to see if the // second entry is in use. Decision must be made as to what to do if this //is the case. 10 //In addition, there may be an entry in the first field of the domain table. // This would be an indication that some binding has been performed by an external tool. // What do we do with self binding if this is the case? // // The self bind domain in this prototype is defined as 0 length Domain in index 1 15 //The impact that the existence of routers might have on this selection needs to be //evaluated. // if(nciSBConfig == CFGLOCAL) // SNVT config src as required by LONMARK for self installing nodes 20 { if(nviSBControl.SBActive) // Self binding is active { EnterState(BINDSTATE_START); //Start the Bind Control State Machine } 25 else { SetSBDomaino; //put us in the self bind domain if not already there!! } 30 } } // nviSBControl is the Network variable that contains the Group name(s) and role selector 35 // nciSBConFIG is the LONMark mandated Network variable that tells whether the device can // self bind or will be installed with a tool H when(nvupdateoccurs(nviSBControl)) when(nvupdate_occurs(nciSBConfig)) WO 98/57239 PCT/US98/11843 - 65 { intj; nviSBControl.SBActive = nviSBControl.SBActive; nviSBControl.SBRole = nviSBControl.SBRole; 5 for(j = 0; j < 26; j++) nviSBControl.SBGroup[j] = nviSBControl.SBGroup[j]; CheckSelfBindo; } // addition for self binding control NV 10 typedef struct SBControl { unsigned SBRole; unsigned SBActive; char SBGroup[26]; } SBControl; 15 // variable id's #define VARID SPACETEMP 1 #define VARID SPACETEMPSET 2 #define VARID HEATOVERRIDE 3 20 #define VARID HEATCONTROL4 #define VARID MODEOVERRIDE 5 #define VID SAFANSTS 20 #define VID RAFANSTS 21 25 #define VID SAFANISTS 22 #define VID RAFAN1STS 23 #define VID SAFAN2STS 24 #define VIDRAFAN2STS 25 #define VID SYSMODE 26 30 #define VID SASMOKE 27 #define VID RASMOKE 28 #define VIDOAT 29 #define VID SAT 30 #define VID RAT 31 35 #define VID EFFOCC 32 #define VID HVACEMERG 33 #define VID DLCSHED 34 #define VID TODEV 35 #define VID TRMLLOAD 36 WO 98/57239 PCT/US98/11843 - 66 #define VID AVGSPACETEMP 37 #define VID SAFLOWUTML 38 #define VID COOLUTML 39 #define VID OKSTARTMAC 40 5 #define VID OKSTARTSCAP 41 #define VID OKSTARTSATC 42 #define VID OKSTARTSAHC 43 10

Claims (33)

1. A distributed control system comprising: a communication infrastructure; and a plurality of devices which communicate over the communication 5 infrastructure, each of the plurality of devices comprising: memory component storing at least information about data desired by the device for operation, or information about data which can be supplied by the device to other devices desiring that data for operation; communication component interfacing the device to others of the plurality of 10 devices communicating over the communication infrastructure; physical device, operating as an interface to the environment of the system; and device controller connected to the communication component, physical component, and memory component, and capable of at least identifying sources of data desired by the device or supplying data requested by 15 other devices based on information stored in the memory component.

2. The distributed control system of claim 1 wherein a device controller in a device which requests data on the communication infrastructure includes an apparatus for selecting among pieces of data of the same type received from two or more other 20 devices.

3. The distributed control system of claim 1 wherein a device controller in a device which requests data on the communication infrastructure includes an apparatus for combining data of the same type received from two or more other devices. 25

4. The distributed control system of claim 1 wherein the communication component receives communication from other devices via an address unique to that device. 30 5. The distributed control system of claim 1 wherein the communication component receives communication from other devices via an address common to all devices. WO 98/57239 PCT/US98/11843 - 68 6. The distributed control system of claim 1 wherein the communication component requests desired data from other devices on the communication infrastructure using an address common to all devices. 5

7. The distributed control system of claim 1 wherein the communication component requests desired data from other devices on the communication infrastructure using a unique address for each device. 10 8. The distributed control system of claim 1 wherein the device controller requests both necessary and optional data needed by the device from other devices on the communication infrastructure.

9. The distributed control system of claim 8 wherein the device controller includes 15 a mechanism for choosing a default value if optional data is not available from another device on the communication infrastructure.

10. A device for use in a distributed control system, the device utilizing a communication infrastructure with a plurality of other devices comprising: 20 memory component storing at least information about data desired by the device for operation, or information about data which can be supplied by the device to other devices desiring that data for operation; communication component interfacing the device to others of the plurality of devices communicating over the communication infrastructure; 25 physical device , operating as an interface to the environment of the system; and device controller connected to the communication component, physical component, and memory component, and capable of at least identifying sources of data desired by the device or supplying data requested by another of the plurality of devices based on information stored in the 30 memory component. WO 98/57239 PCT/US98/11843 - 69 11. The device for use in a distributed control system of claim 10 wherein the device selects among pieces of data of the same type received from two or more other devices.

12. The device for use in a distributed control system of claim 10 wherein the device 5 combines data of the same type received from two or more other devices.

13. The device for use in a distributed control system of claim 12 wherein the communication component receives communication from other devices via an address unique to that device. 10

14. The device for use in a distributed control system of claim 12 wherein the communication component receives communication from other devices via an address common to all devices. 15 15. The device for use in a distributed control system of claim 12 wherein the communication component requests desired data from other devices on the communication infrastructure via an address unique to that device.

16. The device for use in a distributed control system of claim 12 wherein the 20 communication component requests desired data from other devices on the communication infrastructure using an address common to all devices.

17. The device for use in a distributed control system of claim 12 wherein the memory component includes information about both necessary and optional data needed 25 by the device.

18. The device for use in a distributed control system of claim 12 wherein the device controller includes a mechanism for choosing a default value if optional data is not available from another device on the communication infrastructure. 30

19. A method of distributed control comprising the steps of: attaching one or more devices to a communication infrastructure; WO 98/57239 PCT/US98/11843 - 70 allowing each device to communicate with other devices on the communication infrastructure to determine what data that device can supply to other devices, and to determine from which other devices it may obtain data it needs to operate. 5

20. The method of distributed control of claim 19 wherein: one or more of the devices operating on the communication infrastructure supply the same data to one or more other device on the communication infrastructure; and, 10 devices receiving the same data from more than one source modifying their operation based on recognition that the same data has been received from more than one source.

21. The method of distributed control of claim 19 wherein devices on the 15 communication infrastructure request both necessary and optional data from other devices on the communication infrastructure.

22. The method of distributed control of claim 19 wherein the step of allowing the device to communicate with other devices on the communication infrastructure 20 comprises the steps of: each device broadcasting its presence on the communication infrastructure; each device which operates on the communication infrastructure recognizing the broadcast, and requesting needed data from that device. 25 23. The method of distributed control of claim 22 further comprising the step of: storing the identity of a requesting device for later use in sending that data specifically to the requesting device if the requested data can be supplied; and sending the requesting device a notification that the supplying device can supply 30 the requested data.

24. The method of distributed control of claim 22 further comprising the step of: WO 98/57239 PCT/US98/11843 -71 sending the requesting device a notification that the device supplying data can supply the needed in data; and recognizing that the data is needed by another device in the system, for later broadcast over the communication infrastructure. 5

25. The method of distributed control of claim 19 further comprising the step of: assigning a group identifier to each device, at least some of the devices assigned the same group identifier, exchange of data between devices limited to those devices having the same group identifier. 10

26. The method of distributed control of claims 25 wherein: one or more of the devices operation on the communication infrastructure supply the same data to one or more other devices on the communication infrastructure; and 15 devices receiving the same data from more than one device modifying their operation based on recognition that one or more other devices have supplied the same data.

27. The method of distributed control of claims 25 wherein devices on the 20 communication infrastructure request both necessary and optional data from other devices on the communication infrastructure.

28. The method of distributed control of claim 25 wherein the step of allowing each device to communication with other devices on the communication infrastructure 25 comprises the steps of: each device broadcasting it presence on the communication infrastructure; each device which operates on the communication infrastructure recognizing the broadcast, and requesting-needed data from that device. 30 29. The method of distributed control of claim 25 further comprising the step of: WO 98/57239 PCT/US98/11843 - 72 storing the identity of a requesting device for later use in sending the requested data specifically to the requesting device if the requested data can be supplied; and sending the requesting device a notification that the supplying device can supply 5 the requested data.

30. The method of distributed control of claim 25 further comprising the step of: sending the requesting device a notification that the device supplying data can supply the needed data; and 10 recognizing that the data is needed by a device and should later be broadcast over the communication infrastructure.

31. The method of distributed control of claim 25 wherein the group identifier is assigned using a hand-held programmer. 15

32. The method of distributed control of claim 25 wherein the group identifier is assigned using a PC interface card.

33. The method of distributed control of claim 25 wherein the group identifier is 20 assigned using DIP switches.

34. A distributed control system capable of self-configuration, including a plurality of devices comprising: a communication infrastructure; and 25 a plurality of devices which communicate over the communication infrastructure, each device comprising: memory component at least storing information about data desired by the device for operation or information about data which can be supplied by the device to other devices desiring that data for 30 operation, and storing a group identifier; WO 98/57239 PCT/US98/11843 - 73 communication component interfacing the device to others of the plurality of devices communicating over the communication infrastructure; physical device, operating as an interface to the environment of the 5 system; and device controller controlling connected to the communication component, physical component, and memory component, and capable of at least identifying sources of data desired by the device or supplying data requested by another of the plurality of 10 devices, based on information stored in the memory component, including the group identifier.

35. The distributed control system of claim 34 wherein a device which requests data on the communication infrastructure includes an apparatus for selecting among pieces of 15 data of the same type received from two or more other devices.

36. The distributed control system of claim 34 wherein a device which requests data on the communication infrastructure includes an apparatus for combining data of the same type received from two or more other devices. 20

37. The distributed control system of claim 34 wherein the memory component includes information about both necessary and optional data from other devices on the communication infrastructure. 25 38. A device for use in a distributed control system using a communication infrastructure to communicate with one or more other devices within the distributed control system comprising: memory component storing at least information about data desired by the device for operation or information about data which can be supplied by the 30 device to other devices needing that data for operation, and storing a group identifier; WO 98/57239 PCT/US98/11843 - 74 communication component interfacing the device to others of the plurality of other using the communicating infrastructure; physical device, operating as an interface to the environment of the system; and device controller controlling connected to the communication component, 5 physical component, and memory component and capable of at least identifying sources of data desired by the device or supplying data requested by another of the plurality of devices, based on information stored in the memory component, including the group identifier. 10 39. The device for use in a distributed control system of claim 34 wherein a device which requests data on the communication infrastructure includes an apparatus for combining data of the same type received from two or more devices.

40. The device for use in a distributed control system of claim 38 wherein the 15 memory component includes information about both necessary and optional data.

41. The device for use in a distributed control system of claim 38 wherein the group identifier is assigned using a hand-held programmer. 20 42. The device for use in a distributed control system of claim 38 wherein the group identifier is assigned using a PC interface card.

43. The device for use in a distributed control system of claim 38 wherein the group identifier is assigned using DIP switches.