DISTRIBUTED CONTROL USING GROUP CONCEPTS

Abstract: A distributed control system comprising a plurality of devices operating on a communication infrastructure. Each device communicates with each other device to determine what data that device can supply to other devices on the communication infrastructure, if any, and to determine which other devices can supply data that device needs to operate, if any. The invention can be expanded to more complicated systems including numerous similar devices which would not normally be capable of self-configuration by separating the devices into functional groups, and performing the applicants' self-configuration method to the associations of devices, rather than all devices within the system.

Description: 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 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 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 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 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 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 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 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 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 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 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. 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 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. 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 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' 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. 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. 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 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. 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 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 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 space RM1. 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 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 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 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. 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 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 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 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 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 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 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 Lon Works™ based hardware. If very large systems are contemplated, a system adaptable to the use of routers or other large-system 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 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 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- 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 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. 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, 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. 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 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 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. 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 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 temperature setpoint (e.g. 25°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 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 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 each device is capable of identification by other devices in the system via the common list of data types. 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 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 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 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 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 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. "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 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, 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 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 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 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. 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. 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 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 place the heat exchange device at a default setpoint temperature, such as 25°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 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 to be sequential, and standardized, which may ease device design. At step 300 A 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 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 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. 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 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 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 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. 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. 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 328 A. 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 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. 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 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, 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, 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 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 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 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 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 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 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 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. 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 and a group RM IS, 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 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. 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, FL1, 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 AHUl . The device H from group AHUl and the device D from group RM1 are also members of group FLl. One will note from the figure that there are three apparently identical device A's in the system; there are two A devices in group RM1 , and one type A device in group AHUl . Due to the chosen grouping there is no confusion about which devices will use data from which type A device. In group RM1, 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 reflected by the requesting device receiving data from these devices. The A device in group AHUl 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 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 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 RM1. 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 RM1 to be heated with the heat 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 AHUl 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 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 Figure 5. In this figure, multiple rooms on two separate floors, FLl 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 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 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 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 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. 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 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. 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 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 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 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 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. 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 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 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. 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 1 1 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 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 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 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 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. 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 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 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 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 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, 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 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 Address I 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 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 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 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 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, 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 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 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 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 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 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. 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 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 control table. The lamp device stores in its own bind control table the source for the data of type 1. 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 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 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 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 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 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 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 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 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. 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 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 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 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 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 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 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 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 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. 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 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 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. 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, 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 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 1 1, 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 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 that the scope of the invention be defined by the following claims and their equivalents. II II slfbnd.h - Neuron C code for self binding devices // #include <addrdefs.h> #include <msg_addr.h> #include <access.h> #include <string.h> #include <SNVT_CFG.h> #include "GroupNV.h" // increase the number of comm buffers #define SLFMSG_ REQ_GROUP 1 // Broadcast message requesting other nodes within the same group #define SLFMSG_ RSP_GROUP 2 // direct message back to requestor #define SLFMSG_ GET GROUPS 3 // request for SBControl Variable data #define SLFMSG_ SET_GROUPS 4 // modify SBControl Variable data #define SLFMSG_ REQ_BIND 6 // direct message to initiate a bind sequence #define SLFMSG_ RSP_BIND 7 // response to bind initiation message #define SLFMSG_ REQ_ADDR 10 // Broadcast Address Synchronization #define SLFMSG RSP ADDR 1 1 // Broadcast Address Synchronization // definitions used for self binding #define SLFBND MSGCODE 0x30 #define SLFBND MAGIC 97 #defme MAX_GROUP_NAMES 2 #define SIZE_GROUP_NAME 9 #define SIZE VAR NAME 9 typedef unsigned GROUP NAME[SIZE_GROUP_NAME ]; ////////////////////////////////////////////////////////////////////////////////// // 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 REQUEST_GROUP) // the remaining messages are direct using neuron id addressing. // message structure for request bind typedef struct req_bind_data { unsigned long rb varid; } req_bind_data; // message structure for respond bind typedef struct rsp bind data { unsigned long rb varid; unsigned rb_gpid; unsigned rb gpmember; unsigned rb gpsize; } rsp bind data; typedef struct slf address { unsigned slfa flag; // This is a negotiation message unsigned slfa attempt; // attempt sequence number unsigned slfa_domlen; // domain length unsigned[6] slfa domain; / unsigned slfa high subnet; // current highest subnet# unsigned slfa high iode; // current highest node # unsigned slfa high group; // highest current group assignment } slf address data; #defme NEWHIGH 0 #define TRYHIGH 1 #defιne IAMHIGH 2 // Self Binding message structure for data section of message // Self Binding message structure for data section of message typedef struct 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 unsigned sbmsg subnet; unsigned sbmsg node; GROUP_NAME sbmsg groupname; union { req_bind_data rqbdata; rsp_bind_data rsbdata; slf_address_data adrdata; SBControl sbcdata; } sbmsg_data; } slfbnd data; II II SelfBinding Data structures // // Self Binding Variables control table ( held in flash) typedef struct ROLED ATA { unsigned rd_function: 5; // function selector for this node unsigned long rd varid; // variable identifier unsigned rd source: 2; // internal, external or either unsigned rd_default: 2; // default when not available unsigned rd multiple: 4; // action identifier if multiple sources detected long rd_default_val; // if the default is setvalue unsigned rd_nvidx; // NV index unsigned rd numref; // number of external references to this variable unsigned rd_group; // group id for one-to many unsigned rd bndidx; // index to bind control table } ROLEDATA; // defines for rd default: #defme NODEFAULT 0 #define SETVALUE 1 // defines for rd source #defιne INTERNAL 0 #define EXTERNAL 1 #define EITHER2 // defines for rd_type #define ANAIN 0 #define DIGIN 1 #defιne ANAOUT 2 #define DIGOUT 3 #define PSEUDO 4 // defines for rd multiple #define NOMULTIPLE 0 #define AVGMULTIPLE 1 #define SUMMULTIPLE 2 #define MINMULTIPLE 3 #define MAXMULTIPLE 4 #define LSTMULTIPLE 5 // Device Bind Control Table (In Flash) typedef struct BINDCONTROL { 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 bc_addr[NEURON JD _LEN] ; // device address for bound NV unsigned bc gname; // index to group bound to unsigned be next; // index to next bind entry for this variable } BINDCONTROL; // defines for be direction #define INPUT_BIND #define OUTPUT BIND 1 // defines for bc_type #define RFR BIND 0 #define RFR_APPL 1 // defines for bc bind #defme SINGLE BIND 0 #defιne GROUP BIND 1 #define TOALL 1 #define TOONE 2 #define NULL 0 // Structure holds references to other devices in our group(s) #define MAX 3ROUPLIST 30 typedef struct GROUPLIST { int gl gname; // index to group name unsigned gl_addr[NEURON_ID_LEN]; // device address unsigned gl_subnet: 7; unsigned gl current: 1 ; // indicates that binding is complete unsigned gl node; } GROUPLIST; #defιne BINDSTATE_START 0 #defιne BINDSTATE_ADDR 1 #define BINDSTATE NIT 2 #define BINDSTATE_RECFG 3 #define BINDSTATE_NORMAL 4 #define BINDSTATE_DISABLED 5 #define NORMAL_CYCLE 5 #defme ADDRESS_CYCLE 5 // The following variables should be stored in flash or EEPROM in the future // far offchip eeprom GROUP_NAME GroupName[MAX_GROUP_NAMES]; far offchip eeprom BINDCONTROL bndcfg[MAX_BINDCONTROL]; far offchip eeprom boolean NeedData = FALSE; far offchip eeprom boolean GoodRole = FALSE; far offchip eeprom GROUPLIST grplst[MAX_GROUPLIST]; extern far offchip eeprom int ROLEENTRIES; extern far offchip eeprom ROLEDATA slfcfgf]; // Global RAM Variables unsigned CurState BINDSTATE DISABLED; binder state unsigned WaitingForAddress int CURGLIDX // index of the current item in the grouplist being processed int CURSLFIDX // index of the current item in the grouplist being processed unsigned MySubnet = 0; unsigned MyNode unsigned HighSubnet = 0 unsigned HighNode = 0 unsigned HighGroup = 0 unsigned long CurSeqld 0; long DistanceFromHigh 32767; // Timers stimer repeating BndCtrl; // Bind Control Timer // Selfbinding message tag msg_tag bind info(nonbind) TAG_OUT; Self Bind Configuration Input Network Variable (defined in GroupNV.h) network input sd string ("SB Control") SBControl nviSBControl = {0,0,""} ; config network input sd_string ("SB Config") SNVT_confιg_src nciSBConfig = CFG LOCAL; II // START OF SELF BINDING CODE // // utility version of strcpy (no return value) void CopyGroup(unsigned *ostr,const unsigned *istr) { int i; for(i = 0; i < SIZE GROUP NAME ;i++) { ostr[i] = istr[i]; } return; } // utility version of strncmp boolean Compare(const unsigned *ostr,const unsigned *istr,int sz) { int i; for(i = 0; i < sz ;i++) { if(ostr[i] == '\0') if (istr[i] == '\0') return TRUE; else return FALSE; if(ostr[i] != istr[i])return FALSE; } return TRUE; } II II SendSLFMsgO - Send a self bind application message // // inputs - Pointer to Self Bind message data block // destination type // destination neuron id // // outputs - none // void SendSLFMsg(slfbnd_data *slfπιsg,int dest,const unsigned *destnid,int gname_idx) { watchdog_update(); // don't let the watchdog expire msg_out.tag = TAG OUT; msg out.code = SLFBND MSGCODE; msg out. authenticated = FALSE; 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); if(gname_idx != -l) CopyGroup(slftnsg->sbmsg_groupname,GroupName[gname idx]); else memset(slfmsg->sbmsg_groupname,0,SIZE_GROUP_NAME); memcpy(msg_out.data, slfmsg, sizeof(slfbnd_data)); if(dest == TOALL) { msg_out.dest_addr.bcast.type = BROADCAST; msg_out.dest_addr.bcast.domain = 1 ; msg out.dest addr.bcast.subnet = 0; } else { // send message to a specific neuron id msg_out.dest_addr.nrnid.type = NEURON_ID; memcpy(msg_out.dest_addr.nrnid.nid,destnid,NEURON_ID_LEN); } msg_send(); if(CurState == BINDSTATE_NORMAL) BndCtrl = NORMAL CYCLE; // reset the cycle timer if running normally return; } II SendHighAddress() - Send a message containing the current high address // // inputs - contents of the message // // outputs -none // // void SendHighAddressønt flagjnt dest,unsigned *destnid, unsigned xSubnet, unsigned xNode,unsigned long xSeq.unsigned xGroup) { slfbnd data slfmsg; memset(&slfmsg,0,sizeof(slfbnd_data)); slftnsg.sbmsg ype = SLFMSG_RSP_ADDR; slfmsg. sbmsg_data.adrdata.slfa_flag = flag; slfmsg. sbmsg_data.adrdata.slfa_attempt = 0; slfmsg.sbmsg_data.adrdata.slfa_seq = xSeq; slfmsg.sbmsg data.adrdata.slfa high subnet = xSubnet; slfmsg.sbmsg_data.adrdata.slfa_high_node = xNode; slfmsg. sbmsg data.adrdata.slfa high group = xGroup; SendSLFMsg(&slfmsg,dest,destnid,- 1 ); return; } II II Self Bind Message Generation routines // II SendGroupRequestMessageO - Ask for all other devices in the same group to identify // themselves. This message is only generated if this device // requires external information in oreder to perform the // selected application. // void SendGroupRequestMessageO { int i; slfbnd data slf sg; // self binding message structure slfmsg.sbmsg type = SLFMSG REQ GROUP; i = 0; while(GroupName[i][0] != '\0') { SendSLFMsg(&slfmsg,TOALLNULL,i); i++; } } II II CheckGroupName() - Check a group name // // inputs - Pointer to group name to check // // outputs -TRUE if name matches // FALSE if no match // int CheckGroupName(GROUP_NAME grname) { int i; for(i = 0; i < MAX_GROUP_NAMES; i++) { if(Compare(grname,&GroupName[i][0],8))return(i); } return(-l); } II CheckNewGroupNameO - See if the group name has changed and take the appropriate action(s)l. inputs - none outputs -none void CheckNewGroupNameO { int ij,k; char ch; if(!nviSBControl.SBActive) // If self bind is not active - forget it. return; // check for a valid role NeedData = FALSE; GoodRole = FALSE; for(i = 0; i < ROLEENTRIES;i++) { if((!slfcfg[i].rd_function) || (slfcfg[i].rd_function == nviSBControl.SBRole)) { 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 scan any more! ! } if(!GoodRole) return; // didn't find the role // role is valid - parse the group name(s) i = 0; j = 0; k = 0; while((ch = nviSBControl.SBGroup[i]) != '\0') { if(j = MAX_GROUP_NAMES) return; // too many semicolons if(ch = • ; • ) { GroupName[j][k] = '\0'; // nul terminate the groupname k = 0; j++; } else GroupName[j][k] = ch; // copy the character k++; if(k > 8) // to many characters in the group name { GroupName j][k-l] = '\0'; // nul terminate the groupname return; } } i++; } GroupNameϋP] = 'W; // nul terminate the groupname // here's where we start the whole thing going! ! // Request id from other devices in our group(s) SendGroupRequestMessageO; return; } II II ClearBindConfigO - Clear all of the binding information! ! // // - This is a brute force re-init of the self binder, current use is // to reset the device for testing purposes. For actual production use // see the TODO comments. // // // inputs - none // // outputs -none // void ClearBindConfigO { domain struct dentry; address struct adentry; nv struct nventry; int i,k; //clear the domain table dentry = *(access_domain(l)); dentry.len = OxFF; dentry.id[0] = 0; dentry. subnet = 0; dentry .node = 0; for(i = 0; i < AUTH_KEY_LEN; i++)dentry.key[i] = OxFF; update_domain(&dentry,0); //update_domain(&dentry,l); //reset the bind control tables for(i = 0; i < MAX BINDCONTROL; i++) { // TODO send a message to the other node for each bind to terminate the bind bndcfg[i].bc_roleidx = -1 ; // clear the bind control table bndcfg[i].bc_next = -1 ; // clear the bind control table } for(i = 0; i < ROLEENTRIES;i++) { slfcfg[i].rd_numref = 0; slfcfg[i].rd_group = 0; slfcfg[i].rd_bndidx = -1 ; } for(i = 0; i < MAX_GROUPLIST;i++) { grplst[i].gl_gname = -1 ; grplst[i].gl_subnet = 0; } watchdog_update(); // most of this is happening in flash // takes a long time // clear the NV tables k = read only data.nv count; for(i = 0;i <k; i++) nventry = *(access_nv(i)); nventry.nv selector ii = 0x3F; nventry.nv selector o = OxFF - i; nventry. nv_addr_index = OxOF; // No address index update_nv(&nventry,i); } // clear the address table 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; adentry.sn.node = 0; adentry. sn.rpt timer = 14; // 2 second repeat adentry. sn.retry = 4; // 4 retries adentry. sn.tx timer = 12; // 1 second timeout for ackd adentry.sn.subnet = 0; update_address(&adentry,i); } return; } void CheckGRList(unsigned gname_idx,unsigned *nid,unsigned subnet,unsigned node) { int i,j, spareentry; // 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 == -l))spareentry = i; // save in case 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))) { // entry already exists - new device message occurs on reset, set up for a refresh sequence grplst[i].gl_current = FALSE; } } if(i == MAX_GROUPLIST) // no existing entry for this device { // add an entry grplst[spareentry].gl_gname = gname_idx; //eeprom_memcpy(&grplst[spareentry].gl_addr[0],&nid[0],6); 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; } return; } // BINDER STATE MACHINE // II // EnterState() - Switch the binder state machine to a new mode of operation // II inputs - state number to enter II II outputs -none II II void EnterState(int newstate) { switch(newstate) { case BINDSTATE START: BndCtrl = 1 ; // Start the Bind Control State Machine CurState = BINDSTATE_START; break; case BINDSTATE_ADDR: // Obtain a unique subnet and node id within // the Self Bind Domain WaitingForAddress = 1 ; CurState = BINDSTATE ADDR; break; case BINDSTATE INIT: // Initialize self binding data CurState = BINDSTATE NIT; break; case BINDSTATE_RECFG: // Re-initialize self binding data after error CurState = BINDSTATE RECFG; break; case BINDSTATE_NORMAL: // Normal binder operation BndCtrl = NORMAL CYCLE; switch to 5 second cycle CurState = BINDSTATE_NORMAL; break; case BINDSTATE DISABLED: BndCtrl = 0; // Stop the Bind Control State Machine CurState = BINDSTATEJDISABLED; break; default: break; } } // // CheckSelfBindO - Self bind configuration may have changed // // inputs - none // // outputs -none // // void CheckSelfBindO { if((nviSBControl.SBActive = 0)||(nciSBConfιg != CFG LOCAL)) // Not active - do we have to clean up? { if(CurState != BINDSTATE DISABLED) // we were active - reset the bind tables { timers_off(); ClearBindConfigO; EnterState(BINDSTATE_DISABLED); } } else { if((nviSBControl.SBActive)&&(nciSBConfig == CFG_LOCAL)) { EnterState(BINDSTATE_START); } } return; } II II Self Bind Message Handler routines // void PrcMsgReqGroup(slfbnd_data *inmsg,int gname idx) { // A device is asking who else is in it's group slfbnd data slfmsg; // self binding message structure CheckGRList(gname_idx,inmsg->sbmsg_nid,inmsg->sbmsg_subnet,inmsg->sbmsg_node); memset(&slfmsg,0,sizeof(slfbnd_data)); slfmsg.sbmsg ype = SLFMSG RSP 3ROUP; SendSLFMsg(&slfmsg,TOONE,inmsg->sbmsg_nid,gname_idx); } 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 != -l) { CheckGRList(gname_idx,inmsg->sbmsg_nid,inmsg->sbmsg_subnet,inmsg->sbmsg_node); } } II PrcMsgGroupsO - process message setting or getting group names // // inputs - pointer to bind request message // // outputs -none // void PrcMsgGroups(slfbnd_data *inmsg) { slfbnd data slfmsg; // self binding message structure unsigned neuronid[NEURON_ID_LEN]; intj; memcpy(&slfrnsg,inmsg,sizeof(slfbnd_data)); if(inmsg->sbmsg_type == SLFMSG_GET_GROUPS) { memcpy(&slfmsg.sbmsg_data.sbcdata, &nviSBControl, sizeof(SBControl)); } else { nviSBControl.SBActive = slfmsg.sbmsg data.sbcdata.SBActive; nviSBControl.SBRole = slfmsg. sbmsg data.sbcdata.SBRole; for(j = 0; j < 26; j++) nviSBControl. SBGroup[j] = slfmsg.sbmsg data.sbcdata.SBGroupjj]; } SendSLFMsg(&slftnsg,TOALL,inmsg->sbmsg_nid,- 1 ); if(inmsg->sbmsg_type == SLFMSG_SET_GROUPS) CheckSelfBindO; return; } II SendBindResponse() - Send a response to a bind request // // inputs - pointer to bind request message // index to the self bind configuration table entry // index to the self bind control table entry // // outputs -none // void SendBindResponse(int bndidx,int slfidx,int gname idx) { slfbnd data slfmsg; // self binding message structure unsigned neuronidfNEURON ID LEN]; intj; memset(&slftnsg,0,sizeof(slfbnd_data)); slfmsg.sbmsg ype = SLFMSG_RSP_BIND; slfmsg.sbmsg_data.rsbdata.rb_varid = slfcfgfslfidx], rd varid; slfmsg.sbmsg_data.rsbdata.rb_gpid = slfcfg[slfidx].rd_group; if( ! slfcfgfslfidx] .rd group) slfmsg.sbmsg data.rsbdata.rb gpmember = 0; // not a group bind else slfmsg.sbmsg_data.rsbdata.rb_gpmember = slfcfgfslfidx]. rd numref + 1 ; slfmsg. sbmsg data.rsbdata.rb gpsize = 0; // set for unlimited size group in destinations for(j = 0; j < NEURON D_LEN; j++) neuronidfj] = bndcfg[bndidx].bc_addr[j]; SendSLFMsg(&slfmsg,TOONE,neuronid,gname_idx); return; } II II SetupGroupBind() - Setup the internal tables for a group binding // // inputs - pointer to bind request message // index to the self bind configuration table entry // // outputs -none // void SetupGroupBind(int slfidx,int bndidx,slfbnd_data *inmsg,int gname idx) { address struct adentry; nv_struct nventry; int i,j,k; long tmpsel; nventry = *(access_nv(slfcfg[slfιdx].rd_nvidx)); // 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(! slfcfgfslfidx] .rd_group) // not in a group bind { // 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,CurSeqId,HighGroup); slfcfgfslfidx]. rd group = 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. // 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++) { 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 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 adentry. gp.group = slfcfgfslfidx], rd group ; update_address(&adentry,i); break; } } if(i == 15) return; // no entries in the address table - forget it! ! // TODO take some remedial action! ! // update the NV table tmpsel = slfcfgfslfidx] .rd varid & 0x3FFF; nventry .nv_selector_lo = (tmpsel & Oxff); nventry. nv selector hi = (tmpsel » 8); nventry.nv_addr_index = i; update_nv(&nventry,slfcfg[slfidx] .rd nvidx); SendBindResponse(slfcfg[slfidx].rd_bndidx,slfιdx,gname_idx); // modify the binding in the first destination } // Update the binder control table bndcfgfbndidx].bc_varid = slfcfgfslfidx]. rd varid; bndcfg[bndidx].bc_roleidx = slfidx; bndcfgfbndidx].bc_subnet = inmsg->sbmsg_subnet; bndcfg[bndidx].bc_node = inmsg->sbmsg_node; for(j = 0; j < NEURON D LEN; j++) bndcfg[bndidx].bc_addrfj] = inmsg->sbmsg_nid[j]; bndcfg[bndidx].bc_gname = gname idx; bndcfg[bndidx].bc_next = slfcfgfslfidx] .rd_bndidx; // insert this entry at the beginning of the list slfcfgfslfidx] .rd_numref++; slfcfgfslfidx] .rd_bndidx = bndidx; // Send the bind response! ! SendBindResponse(bndidx,slfidx,gname_idx); return; } // // SetupNodeBindO - Setup the internal tables for a subnet/node binding // // inputs - pointer to bind request message // index to the self bind configuration table entry // // outputs -none // void SetupNodeBind(int slfidx,int bndidx,slfbnd_data *inmsg,int gname_idx) { address_struct adentry; nv struct nventry; int i ; long tmpsel; // find a free entry in the address table for(i = 0; i < 15;i++) { adentry = *(access_address(i)); if(adentry.sn.type == UNBOUND) // Unused entry { adentry.sn.type = SUBNET NODE; adentry. sn. domain = 0; adentry.sn.node = inmsg->sbmsg_node; adentry.sn.rpt timer = 14; // 2 second repeat adentry.sn.retry = 4; // 4 retries adentry. sn.tx_timer = 12; // 1 second timeout for ackd adentry.sn.subnet = inmsg->sbmsg_subnet; update_address(&adentry,i); break; } if((adentry.sn.type == SUBNET_NODE) && (adentry. sn. domain == 0) && (adentry.sn.node == inmsg->sbmsg node) && (adentry.sn.subnet == inmsg->sbmsg_subnet)) { break; // found an existing entry for this device! ! } 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 point! ! // update the NV table // idx points to entry in the self bind control table nventry = *(access_nv(slfcfg[slfidx].rd_nvidx)); tmpsel = slfcfgfslfidx] .rd varid & 0x3 FFF; nventry .nv_selector_lo = (tmpsel & Oxff); nventry .nv selector hi = (tmpsel » 8); nventry .nv_addr_index = i; update_nv(&nventry,slfcfgfslfιdx].rd_nvidx); // Update the binder control table bndcfg[bndidx].bc_varid = slfcfgfslfidx] ,rd_varid; bndcfg[bndidx].bc_roleidx = slfidx; bndcfg[bndidx].bc_subnet = inmsg->sbmsg_subnet; bndcfg[bndidx].bc_node = inmsg->sbmsg_node; for(j = 0; j < NEURON_ID_LEN; j++) bndcfg[bndidx].bc_addr[j] = inmsg->sbmsg_nid[j]; bndcfg[bndidx].bc_gname = gname idx; bndcfg[bndidx].bc_next = slfcfgfslfidx] .rd bndidx ; slfcfgfslfidx]. rd bndidx = bndidx; slfcfg[slfidx].rd_numref++; SendBindResponse(bndidx,slfidx,gname_idx); return; II II PrcMsgReqBnd() - Process a request to bind one of our output variables // // inputs - pointer to bind request message // // outputs -none // // void PrcMsgReqBnd(slfbnd_data *inmsg,int gname idx) { 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 for(i = 0; i < ROLEENTRIES;i++) { if(((!slfcfg[i].rd_function) || (slfcfgfi] .rd_function == nviSBControl.SBRole)) && (inmsg->sbmsg_data.rqbdata.rb_varid == slfcfgfi]. rd varid) && (slfcfgfi] .rd_source ! = EXTERNAL)) // EITHER or INTERNAL allowed { // Is there an existing entry for this device ? k = slfcfgfi] .rd bndidx; while(k != -l) { if((bndcfg[k].bc_subnet == inmsg->sbmsg_subnet) && (bndcfg[k].bc_node == inmsg->sbmsg_node)) { // a bind to this device already exists - send a bind response; SendBindResponse(k ,i,gname_idx); // existing entry for this NV! ! return; } k = bndcfg[k].bc_next; } // 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++) { if(bndcfg[k].bc_roleidx == -1) // found a spare entry { if(slfcfg[i].rd_numref — 0) { SetupNodeBind(i,k,inmsg,gname_idx); // Not bound - set up a one-to-one bind } else { SetupGroupBind(i,k,inmsg,gname_idx); // Setup a group bind } break; } } break; // terminate the loop } } } II II PrcMsgRspBnd() - Process a response to bind a variables // // inputs - pointer to bind response message // // outputs -none // // void PrcMsgRspBnd(slfbnd_data *inmsg,int gname idx) { nv_struct nventry; address struct adentry; int i j,k,l; long tmpsel; // Scan the bind control table to see if we need it. for(i = 0; i < ROLEENTRIES;i++) { if(((!slfcfg[i].rd_function) || (slfcfgfi]. rd_function == nviSBControl.SBRole)) && (slfcfgfi]. rd source == EXTERNAL) && (inmsg->sbmsg_data.rsbdata.rb_varid == slfcfgfi]. rd varid)) { // Has this binding already been made? k = slfcfg[i].rd_bndidx; // scan the dynamic binder control table for this entry while(k != -l) { if((bndcfg[k].bc_subnet == inmsg->sbmsg_subnet) && (bndcfg[k].bc_node == inmsg->sbmsg_node)) { // entry already exists! ! break; } k = bndcfgfk].bc_next; } if(k == -l) { // find a spare entry in the dynamic binder control table for(k = 0; k < MAX_BINDCONTROL; k++) { if(bndcfg[k].bc_roleidx == - 1 ) // found a spare entry { // Update the binder control table bndcfg[k].bc_varid = slfcfgfi]. rd varid; bndcfg[k].bc_roleidx = i; bndcfg[k].bc_subnet = inmsg->sbmsg_subnet; bndcfg[k].bc ιode = inmsg->sbmsg_node; for(j = 0; j < NEURON JD_LEN; j++) bndcfg[k].bc_addr[j] = inmsg->sbmsg_nid[j]; bndcfg[k].bc_gname = gname idx; // set up the link info slfcfgfi]. rd_numref++; bndcfg[k].bc_next = slfcfgfi]. rd bndidx; slfcfgfi]. rd bndidx = k; break; } } } if(k == MAX_BINDCONTROL)return; // no spare entries nventry = *(access_nv(slfcfg[i].rd_nvidx)); // Is this a group bind?? if(inmsg->sbmsg_data.rsbdata.rb_gpmember) { if(slfcfg[i].rd_group == 0) // only do this the first time { slfcfgfi]. rd_group = inmsg->sbmsg_data.rsbdata.rb_gpid; // we need to make an entry in the address table for the group for(l = 0; l < 15;l++) { adentry = *(access_address(l)); if(adentry.sn.type == UNBOUND) // Unused entry { adentry. gp.type = 1 ; // high bit in type indicates group adentry. gp. size = 0; // this one plus two others adentry.gp.domain = 0; adentry. gp.member = 0; adentry. gp.rpt timer = 14; // 2 second repeat adentry. gp. retry = 4; II Λ retries adentry. gp. tx timer = 12; II 1 second timeout for ackd adentry. gp. group = inmsg- >sbmsg_data.rsbdata.rb_gpid; update_address(&adentry,l); nventry. nv addr index = 1; // entry in the address table required for group bind break; } } if(i = 15) return; // no entries in the address table - forget it! ! } } // update the NV table tmpsel = slfcfgfi]. rd_varid & 0x3 FFF; nventry .nv_selector_lo = (tmpsel & Oxff); nventry.nv selector hi = (tmpsel » 8); update_nv(&nventry,slfcfg[i].rd_nvidx); break; // terminate the loop } // // PrcMsgReqAddr() - Process a message requesting the current high address II II inputs - Pointer to the request message II II outputs -none II II comments - This device responds if the number of retries indicated in the message II is greater than its difference from the high address. (if known) II void PrcMsgReqAddr(slfbnd_data *inmsg) { if((CurState != BINDSTATE_START) && (CurState != BINDSTATE ADDR)) { if(inmsg->sbmsg_data.adrdata.slfa_attempt > DistanceFromHigh) {// respond to the request SendHighAddress(NEWHIGH,TOONE,inmsg->sbmsg_nid, HighSubnet,HighNode,CurSeqId,HighGroup); } } return; } II PrcMsgRspAddr() - Process a message containing the current high address // // inputs - Pointer to the response message // // outputs -none // // void PrcMsgRspAddr(slfbnd_data *inmsg) { unsigned xSubnet; 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? // did we receive different sequence id's? if(inmsg->sbmsg_data.adrdata.slfa_flag == NE WHIGH) { xSubnet = inmsg->sbmsg_data.adrdata.slfa_high_subnet; xNode = inmsg->sbmsg_data.adrdata.slfa_high_node; xSeq = inmsg->sbmsg_data.adrdata.slfa_seq; if(WaitingForAddress || (xSeq == CurSeqld)) { if(((xSubnet == HighSubnet) && (xNode > HighNode)) || (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; HighSubnet = xSubnet; HighNode = xNode; CurSeqld = xSeq; DistanceFromHigh = ((HighSubnet-MySubnet)*256) + (HighNode - MyNode); } } else {// TODO: Broadcast an error indication that we have two parallel sequences // we'll figure out what to do with this later. } II II ProcessStartStateO - Perform any initialization required by the Binder // // inputs - none // // outputs -none // // comments - State is entered at every start up of the device // void SetSBDomain() { domain_struct dentry; unsigned i; // Check to see whether we already have a valid subnet and node dentry = *(access_domain(l)); // Second domain entry is zero length and used for Broadcasting within the domain if(dentry.len == OxFF) // Not in use - Put us in the self bind domain! ! { dentry.subnet = 9; dentry .node = 9; dentry.len = 0; // 0 length domain for(i = 0; i < AUTH_KEY_LEN; i++) // no authentication! ! (yet) dentry.keyfi] = OxFF; update_clone_domain(&dentry, 1 ); // inserts this device into "self binding domain" return; } void ProcessStartStateO { domain struct dentry; // Check to see whether we already have a valid subnet and node dentry = *(access_domain(l)); // Second domain entry is zero length and used for Broadcasting within the domain MySubnet = 0; MyNode = 0; if(dentry.len = OxFF) // Not in use - Self Binding NOT started yet - let's start it!! { ClearBindConfigO; // clear Network image and bind control stuff SetSBDomainO; EnterState(BINDSTATE ADDR); // Enter address negotiation state } else { if(dentry.len = 0) // already in the zero length domain { // check the valid address flag dentry = *(access_domain(0)); // first domain entry is the actual node address if((dentry.len != Oxff) && (dentry.subnet != 0) && (dentry.subnet != 0)) { // assume our current address is valid. MySubnet = dentry.subnet; MyNode = dentry .node; EnterState(BINDSTATE NIT); // move to the next state } else EnterState(BINDSTATE_ADDR); // Enter address negotiation state II ProcessAddressState() Ensure that we obtain a valid subnet / node // address prior to any other processing. // // inputs - none // // outputs -none // // void ProcessAddressState() { domain struct dnew; unsigned i; slfbnd data slfmsg; // 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 if(WaitingForAddress) { if( WaitingForAddress > 10) //20 seconds - setup to use subnet 1 node 1 HighSubnet = i ; HighNode = 0: HighGroup = 0 // set the high group id to 0 CurSeqld = 0 for(i = 0; i < NEURON ID LEN; i++)CurSeqId crcl6(CurSeqId,read_only_data.neuron_id[i]); else { HighSubnet = 0; HighNode = 0; // Broadcast an address request slfmsg.sbmsg ype = SLFMSG_REQ_ADDR; slfmsg.sbmsg_data.adrdata.slfa_attempt = WaitingForAddress++; SendSLFMsg(&slfmsg,TOALL,NULL,- 1 ); return; } // we got an address dnew = *(access_domain(0)); HighNode++; if(HighNode > 1 10) // leave room for other devices within the subnet { HighSubnet++; HighNode = l ; } dnew.len = 1 ; dnew.id[0] = 0x01 ; dnew.subnet = HighSubnet; dnew. node = HighNode; for(i = 0; i < AUTH_KEY_LEN; i++)dnew.key[i] = OxFF; MySubnet = HighSubnet; MyNode = HighNode; update_domain(&dnew,0); DistanceFromHigh = 0; // we are the highest address Broadcast a "new high" message SendHighAddress(NEWHIGH,TOALL,NULL, HighSubnet,HighNode,CurSeqId,HighGroup); EnterState(BINDSTATE NIT); // Enter self bind initialization state } II II ProcessInitStateO- Perform any required initialization after we have a // valid address // // inputs - none // // outputs -none // // void ProcessInitStateO // Self Binder Initialization phase { EnterState(BINDSTATE NORMAL); CheckNewGroupNameO; return; } void ProcessNormalStateO // Self Binder Normal Operation { // check the Group List to see if we have anything to do intj; slfbnd data slfmsg; // Any other housekeeping should be performed here. if(NeedData) { for(; CURGLIDX < MAX GROUPLIST; CURGLIDX++) { if((!gφlst[CURGLIDX].gl_current)&& (gφlst[CURGLIDX].gl_subnet != 0)) { for(j = CURSLFIDX;j < ROLEENTRIESy++) { if((!slfcfgfj].rd_function) || (slfcfgfj].rd_function == nviSBControl.SBRole)) { if(slfcfg[j].rd_source != INTERNAL) // this variable could come from elsewhere { // ask the device whether it can supply this variable memset(&slfmsg,0,sizeof(slfbnd_data)); slfmsg.sbmsg type = SLFMSG REQ BIND; slfmsg. sbmsg_data.rqbdata.rb_varid = slfcfg[j].rd_varid; SendSLFMsg(&slfmsg,TOONE,gφlst[CURGLIDX].gl_addr,gφlstfCURGLIDX].gl_gname); CURSLFIDX = ++j ; // set up for the next entry return; } } } // check to see if we need to clean up these bindings for some reason // This entry in the device group list is fully processed gφlst[CURGLIDX].gl_current = TRUE; CURSLFIDX = 0; } } CURGLIDX = 0; } return; } II II Binder timing loop // // inputs - none // // outputs -none // when(timer_expires(BndCtrl)) { switch(CurState) { case BINDSTATE START: ProcessStartStateO; // This occurs on power up or reset. break; case BINDSTATE ADDR: ProcessAddressState(); // Address Negotiation phase break; case BINDSTATE INIT: ProcessInitStateO; // Self Binder Initialization phase break; case BINDSTATE RECFG: // TODO: An address or sequence error was detected // reconfigure (later) break; case BINDSTATE NORMAL: // TODO: Binder Normal State do some integrity checking ProcessNormalStateO; // Self Binder Initialization phase break; default: break; } II II Incoming Message Handler // when(msg_arrives(SLFBND_MSGCODE)) { slfbnd data bndmsg; int gname_idx; if(msg_in.len <= sizeof(slfbnd_data)) // Is the message length correct? { memcpy(&bndmsg,&msg_in.data[0],sizeof(slfbnd_data)); if(bndmsg.sbmsg_magic == SLFBND MAGIC) // 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) { case SLFMSG_REQ_ADDR: // Broadcast address arbitration message PrcMsgReqAddr(&bndmsg); break; case SLFMSG RSP ADDR: // Broadcast address arbitration message PrcMsgRspAddr(&bndmsg); break; case SLFMSG GET GROUPS: // request for SBControl Variable data case SLFMSG SET GROUPS: // modify SBControl Variable data PrcMsgGroups(&bndmsg); break; default: break; if(CurState == BINDSTATE NORMAL) { // These message can only be processed after initialization is complete gname idx = CheckGroupName(bndmsg.sbmsg groupname); if(gname_idx != -l) { switch (bndmsg.sbmsg_type) { case SLFMSG REQ GROUP: // Broadcast message requesting other nodes within the same group PrcMsgReqGroup(&bndmsg,gname_idx); break; case SLFMSG RSP GROUP: // direct message back to requestor PrcMsgRspGroup(&bndmsg,gname_idx); break; case SLFMSG REQ BIND: // direct message to initiate a bind sequence PrcMsgReqBnd(&bndmsg,gname_idx); break; case SLFMSG RSP BIND: // response to bind initiation message PrcMsgRspBnd(&bndmsg,gname_idx); break; default: break; } } // Throw away any other messages. when(msg arrives) { } void InitSelfBindO { // Should be called from the "when(reset)" event. // // 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. // 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 // The impact that the existence of routers might have on this selection needs to be // evaluated. // if(nciSBConfig == CFG LOCAL) // SNVT config src as required by LONMARK for self installing nodes { if(nviSBControl.SBActive) // Self binding is active { EnterState(BINDSTATE START); // Start the Bind Control State Machine else { SetSBDomain(); // put us in the self bind domain if not already there!! } } } II nviSBControl is the Network variable that contains the Group name(s) and role selector // nciSBConFIG is the LONMark mandated Network variable that tells whether the device can // self bind or will be installed with a tool // when(nv_update_occurs(nviSBControl)) when(nv_update_occurs(nciSBConfιg)) { intj; nviSBControl.SBActive = nviSBControl.SBActive; nviSBControl.SBRole = nviSBControl.SBRole; for(j = 0; j < 26; j++) nviSBControl.SBGroupfj] = nviSBControl.SBGroupfj]; CheckSelfBindO; } // addition for self binding control NV typedef struct SBControl { unsigned SBRole; unsigned SBActive; char SBGroup[26]; } SBControl; // variable id's #defιne VARID SPACETEMP #define VARID_SPACETEMPSET #define VARID HEATOVERRIDE #define VARID HEATCONTROL4 #define VARID MODEOVERRIDE #define VID_SAFANSTS 20 #define VID_RAFANSTS 21 #define VID_SAFAN1STS 22 #define VIDJR.AFAN1STS 23 #defme VID_SAFAN2STS 24 #define VID_RAFAN2STS 25 #define VID_SYSMODE 26 #define VID_SASMOKE 27 #define VID_RASMOKE 28 #defme VIDJDAT 29 #define VID_SAT 30 #defιne VID tAT 31 #defme VID_EFFOCC 32 #define VID_HVACEMERG 33 #define VIDJDLCSHED 34 #define VID_TODEV 35 #define VID TRMLLOAD 36 #defme VID AVGSPACETEMP 37 #define VID_SAFLOWUTML 38 #define VID_COOLUTML 39 #defme VID OKSTARTMAC 40 #define VID_OKSTARTSCAP 41 #define VID_OKSTARTSATC 42 #defιne VID OKSTARTSAHC 43

Claims: CLAIMS 1. A distributed control system comprising: a communication infrastructure; and a plurality of devices which communicate over the communication 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 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 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 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. 4. The distributed control system of claim 1 wherein the communication component receives communication from other devices via an address unique to that device. 5. The distributed control system of claim 1 wherein the communication component receives communication from other devices via an address common to all devices. 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. 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. 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 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: 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; 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 memory component. 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 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. 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. 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 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 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. 19. A method of distributed control comprising the steps of: attaching one or more devices to a communication infrastructure; 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. 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, 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 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 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. 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 the requested data. 24. The method of distributed control of claim 22 further comprising the step of: 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. 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. 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 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 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 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. 29. The method of distributed control of claim 25 further comprising the step of: 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 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 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. 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 assigned using DIP switches. 34. A distributed control system capable of self-configuration, including a plurality of devices comprising: a communication infrastructure; and 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 operation, and storing a group identifier; 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 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 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 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. 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. 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 device to other devices needing that data for operation, and storing a group identifier; 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, 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. 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 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. 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.

Inventors: BAARS BRUCE T, BOTIC JAMES, DABHOLKAR HARSHA M, GELON MICHAEL, HAGAR MELVIN L JR, JAMES SIMON T, RADFORD WILLIAM M, SHAVIT GIDEON, BAARS, BRUCE, T., BOTIC, JAMES, DABHOLKAR, HARSHA, M., GELON, MICHAEL, HAGAR, MELVIN, L., JR., JAMES, SIMON, T., RADFORD, WILLIAM, M., SHAVIT, GIDEON
Applicants: HONEYWELL INC, HONEYWELL INC.
Application year: 1998
Main classification: G05B19
IPC codes: G05B19