EP1002261A1 - Verteiltes steuerungssystem, welches gruppenentwurfe verwendet - Google Patents
Verteiltes steuerungssystem, welches gruppenentwurfe verwendetInfo
- Publication number
- EP1002261A1 EP1002261A1 EP98930090A EP98930090A EP1002261A1 EP 1002261 A1 EP1002261 A1 EP 1002261A1 EP 98930090 A EP98930090 A EP 98930090A EP 98930090 A EP98930090 A EP 98930090A EP 1002261 A1 EP1002261 A1 EP 1002261A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- data
- devices
- distributed control
- communication infrastructure
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Program-control systems
- G05B19/02—Program-control systems electric
- G05B19/04—Program control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/042—Program control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
- G05B19/0421—Multiprocessor system
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Program-control systems
- G05B19/02—Program-control systems electric
- G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
- G05B19/41845—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by system universality, reconfigurability, modularity
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Definitions
- 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.
- 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.
- 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.
- devices rely on the computer's processor to handle device configuration.
- the devices in the system would be able to self-configure without the help of a centralized control device.
- 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.
- 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.
- FIG. 1 illustrates a simple group of devices 1.
- 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.
- 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.
- 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.
- FIG. 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.
- 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.
- 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.
- 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.
- the memory component which relates to the chosen communication component or method chosen, and other factors.
- the memory will also contain information about group members and the group associations of data to be supplied or requested by a device.
- 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.
- the physical component 2C is the light switch.
- Some devices may actually comprise several physical components working together.
- 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 WorksTM 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 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.
- 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.
- a unique address determined during self- configuration is used to send messages specifically to that device.
- 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.
- 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.
- the sending device 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- a heat exchange device may receive actual temperature data from both a thermostat device and an independent thermometer unit.
- 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.
- 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.
- 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.
- 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.
- FIG. 3 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.
- 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 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 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.
- the new device 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.
- a communication infrastructure such as a communication bus
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- the requesting device 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.
- 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.
- 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.
- 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.
- 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.
- group identifier For example, all light switch devices and the lamp device in one room might be assigned to group RM1.
- 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.
- 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.
- 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.
- FL1, RM1, and AHUl 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.
- 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 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.
- a system is shown in Figure 5.
- 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.
- 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.
- Group assignments 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.
- 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.
- 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.
- 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.
- grouping 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.
- the new device stores the responding device's address in its memory component, as before.
- the new device 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.
- each group a device belongs to is also associated with a desired control function for that group.
- 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.
- 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.
- 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.
- 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 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.
- 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.
- 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.
- Table 5 contains a list of devices which are in the same group as this device.
- index variable 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.
- Index Group member list index Address I Index to Data Item in Data Item Control Table
- groups 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
- the temperature control device in the other room is thus configured with groups RM2 and AHU.
- 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.
- 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.
- the light switch device 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.
- 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.
- the temperature control device from RM1 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.
- 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.
- the temperature control device in group RM1 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.
- 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.
- 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.
- 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.
- 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.
- the switch device from group RM2 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.
- typedef struct rsp bind data ⁇ unsigned long rb varid; unsigned rb_gpid; unsigned rb gpmember; unsigned rb gpsize; ⁇ rsp bind data;
- GROUP_NAME sbmsg groupname union ⁇ req_bind_data rqbdata; rsp_bind_data rsbdata; slf_address_data adrdata;
- 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;
- 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;
- 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;
- SB Control network input sd string
- SBControl nviSBControl ⁇ 0,0,”” ⁇
- config network input sd_string SB Config
- SNVT_conf ⁇ g_src nciSBConfig CFG LOCAL
- BndCtrl NORMAL CYCLE; // reset the cycle timer if running normally
- NeedData TRUE; // we need external data break; // don't need to scan any more! !
- 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++;
- CurState BINDSTATE_START; break; case BINDSTATE_ADDR: // Obtain a unique subnet and node id within
- CurState BINDSTATE NIT; break; case BINDSTATE_RECFG: // Re-initialize self binding data after error
- CurState BINDSTATE RECFG; break; case BINDSTATE_NORMAL: // Normal binder operation
- CurState BINDSTATEJDISABLED; break; default: break; ⁇ ⁇
- PrcMsgGroupsO process message setting or getting group names
- 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
- PrcMsgReqBnd() Process a request to bind one of our output variables
- PrcMsgRspBnd() Process a response to bind a variables //
- ⁇ nv_struct nventry address struct adentry; int i j,k,l; long tmpsel;
- PrcMsgRspAddr() Process a message containing the current high address
- WaitingForAddress 0; // reset the wiating for addresss flag (if set)
- BndCtrl ADDRESS_CYCLE; // 5 second cycle if(WaitingForAddress)
- HighGroup 0 // set the high group id to 0
- 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
- nviSBControl.SBActive nviSBControl.SBActive
- nviSBControl.SBRole nviSBControl.SBRole
- VARID SPACETEMP #def ⁇ ne
- VARID_SPACETEMPSET #define VARID HEATOVERRIDE #define VARID HEATCONTROL4 #define VARID MODEOVERRIDE
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Automation & Control Theory (AREA)
- General Engineering & Computer Science (AREA)
- Manufacturing & Machinery (AREA)
- Quality & Reliability (AREA)
- Selective Calling Equipment (AREA)
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US87263597A | 1997-06-10 | 1997-06-10 | |
| US872635 | 1997-06-10 | ||
| PCT/US1998/011843 WO1998057239A1 (en) | 1997-06-10 | 1998-06-09 | Distributed control using group concepts |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| EP1002261A1 true EP1002261A1 (de) | 2000-05-24 |
Family
ID=25360010
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| EP98930090A Withdrawn EP1002261A1 (de) | 1997-06-10 | 1998-06-09 | Verteiltes steuerungssystem, welches gruppenentwurfe verwendet |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP1002261A1 (de) |
| AU (1) | AU7956098A (de) |
| CA (1) | CA2293822A1 (de) |
| WO (1) | WO1998057239A1 (de) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10142810A1 (de) * | 2001-08-31 | 2003-04-03 | Audi Ag | Automatisierte Buskonfiguration |
| EP1298506A1 (de) * | 2001-09-27 | 2003-04-02 | Siemens Aktiengesellschaft | Dynamischer Zugriff auf Automatisierungsressourcen |
| US8200591B2 (en) * | 2008-01-24 | 2012-06-12 | Rockwell Automation Technologies, Inc. | Self-organized distributed directory |
| BE1018546A3 (nl) * | 2009-05-06 | 2011-03-01 | Pro C Ept Nv | Werkwijze voor modulaire sturing van procestoestellen. |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5165018A (en) * | 1987-01-05 | 1992-11-17 | Motorola, Inc. | Self-configuration of nodes in a distributed message-based operating system |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| NL8902492A (nl) * | 1989-10-06 | 1991-05-01 | Nefit Nv | Werkwijze voor het vervaardigen van een besturingsstelsel voor een verwarmingsinrichting met een brander, en een besturingsstelsel voor een dergelijke inrichting. |
| DE29514502U1 (de) * | 1995-09-08 | 1995-11-23 | Siemens AG, 80333 München | Steckkarte für einen Rechner |
| DE29621724U1 (de) * | 1996-12-14 | 1997-02-20 | Helmut Beyers GmbH, 41066 Mönchengladbach | Vorrichtung zur Steuerung mehrerer Gruppen von untereinander über ein Bussystem vernetzten reversiblen Antrieben |
-
1998
- 1998-06-09 WO PCT/US1998/011843 patent/WO1998057239A1/en not_active Ceased
- 1998-06-09 AU AU79560/98A patent/AU7956098A/en not_active Abandoned
- 1998-06-09 CA CA002293822A patent/CA2293822A1/en not_active Abandoned
- 1998-06-09 EP EP98930090A patent/EP1002261A1/de not_active Withdrawn
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5165018A (en) * | 1987-01-05 | 1992-11-17 | Motorola, Inc. | Self-configuration of nodes in a distributed message-based operating system |
Also Published As
| Publication number | Publication date |
|---|---|
| WO1998057239A1 (en) | 1998-12-17 |
| CA2293822A1 (en) | 1998-12-17 |
| AU7956098A (en) | 1998-12-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8437276B2 (en) | Control systems, commissioning tools, configuration adapters and method for wireless and wired networks design, installation and automatic formation | |
| US11428430B2 (en) | Air conditioning system having multiple outdoor units and multiple indoor units, method and device for operating air conditioning system | |
| US6061604A (en) | RF base repeater for automated residence management system | |
| DK2831680T3 (en) | SYSTEM AND PROCEDURE FOR GROUPING BUILDING AUTOMATION OBJECTS FOR GROUP COMMUNICATION IN A BUILDING AUTOMATION SYSTEM | |
| US7139839B2 (en) | Method and apparatus for assigning a network node address | |
| US11735918B2 (en) | Method and apparatus for electrical load control network | |
| US20090271001A1 (en) | BACnet Protocol MS/TP Automatic MAC Addressing | |
| US20080057872A1 (en) | Method and device for binding in a building automation system | |
| US10747696B2 (en) | Automatic master-slave system and approach | |
| US20060095146A1 (en) | CAN communication for building automation systems | |
| US20130218349A1 (en) | System, method and apparatus for grouping building automation objects for group communication within a building automation system | |
| EP1672293A2 (de) | Mehrere Einheiten Klimaanlage und Verfahren zur Steuerung derselbe | |
| JP2757332B2 (ja) | 電気設備の制御方法 | |
| WO1998057239A1 (en) | Distributed control using group concepts | |
| CN107925582B (zh) | 支持对网络化配电系统的调试 | |
| US20210367848A1 (en) | A method of commissioning a wired communication network | |
| US6538575B1 (en) | Control system, control device and controlled device | |
| JP4513506B2 (ja) | 機器管理システムおよびゲートウェイ装置 | |
| CN116346540B (zh) | 一种自适应的空调网关模块化拓扑系统及扩展方法 | |
| EP1523828B1 (de) | Verfahren zum abtrennen mehrerer hausnetze | |
| CN115576231B (zh) | 控制方法、系统、装置、电子设备、存储介质及程序产品 | |
| JP2002183855A (ja) | オープン化対応分散型ビル監視制御システム | |
| JPH09145134A (ja) | 空気調和システムの制御方法および制御装置 | |
| Knauth et al. | Sarbau-an ip-fieldbus based building automation network | |
| JP3630743B2 (ja) | 集中制御システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
| 17P | Request for examination filed |
Effective date: 19991224 |
|
| AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): DE FR GB IT NL |
|
| 17Q | First examination report despatched |
Effective date: 20010927 |
|
| STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
| 18D | Application deemed to be withdrawn |
Effective date: 20020409 |