US20150163095A1

US20150163095A1 - Approach for automatically setting the device instance of a bacnet device

Info

Publication number: US20150163095A1
Application number: US14/629,377
Authority: US
Inventors: Dean C. Matsen; Michael Underhill
Original assignee: Honeywell International Inc
Current assignee: Honeywell International Inc
Priority date: 2009-05-05
Filing date: 2015-02-23
Publication date: 2015-06-11
Also published as: US8965994B2; US20100286799A1

Abstract

An approach for automatically setting the device instance of a device such as a unitary controller without reliance on a router and/or global controller, or something like a special extension to an associated router and/or global controller. The approach may be implementable entirely by logic in the unitary controller.

Description

This application is a continuation of U.S. patent application Ser. No. 12/435,993, filed May 5, 2009, and entitled “AN APPROACH FOR AUTOMATICALLY SETTING THE DEVICE INSTANCE OF A BACNET DEVICE”.

BACKGROUND

The invention pertains to network devices and particularly to BACnet devices.

SUMMARY

The invention is an approach for automatically setting the device instance of a device such as a unitary controller without reliance on a router and/or global controller or something such as a special extension to an associated router and/or global controller. The approach may be implementable entirely in the unitary controller.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a diagram of a layout for setting an instance of a BACnet device.

DESCRIPTION

It may take an installer some time to manually set the device instance on a BACnet (building automation and control network) device. In some cases, a special tool may be required to do the device instance. The present approach indicates how the device can automatically choose a reasonable device instance. BACnet is a non-proprietary open protocol communication protocol and system developed by the American Society of Heating Refrigeration Air-Conditioning Engineers (ASHRAE) and adopted by the American National Standards Institute (ANSI) as an ANSI/ASHRAE Standard 135-1995.
For BACnet unitary controllers (unitaries) on MS/TP (master-slave/token-passing) networks, there is often a BACnet router from an Ethernet to that MS/TP network. The Ethernet and the MS/TP network may be regarded as BACnet LANs (local-area networks). The router device instance may be used as a basis for the other devices on that MS/TP network. For example, if the router has a device instance of 10000, the unitary controllers may automatically determine their device instances to be 10001, 10002, 10003, and so on. This computation may be based on an MAC (media access control) address of the MS/TP device, which is unique on that MS/TP network.
Two versions of the present approach are noted. The first version is suitable for system designs where BACnet routers may have just one MS/TP network. The second version accounts for routers that may have multiple MS/TP networks.
A benefit of the present approach is that it can be used entirely without any special BACnet extensions to the router/global controller (global) itself. The global controller may generally include a router. The present approach may be implemented entirely in the unitary controller. What is needed is for the unitary controller to implement an algorithm indicated herein.
As noted, the present approach is for automatically addressing unitaries. A goal of the first version may be that unitary controllers reconfigure their device instances to be equal to (global controller device instance)+(unitary MAC address). This scheme differs from other approaches in that virtually all of the logic for doing the auto-addressing is in the unitary rather than in the global controller and/or router.
A goal of the second version is that unitary controllers reconfigure their device instances to be equal to (global controller device instance)+(global controller MAC address−120)*100+(unitary MAC address). The “100” may be regarded as spacing among the global controllers so that there is “room” for unitary controller device instances.
FIG. 1 is a diagram of the present approach for setting an instance of a BACnet device. A BACnet router and/or global controller 11 may have a device instance, D_G=1000. Router or controller 11 may provide an “I Am” message which indicates “I am 1000” on a line 12. Router or controller 11 may provide on a line or LAN 13 an indication “MAC M_G=120”. LAN or line 13 may be an MS/TP network. A unitary controller 14, which is connected to line 13, may have “MAC M₁=1”, and a unitary controller 15, which also is connected to line 13, may have “MAC M₂=2”. Other unitary controllers may be connected to line 13. A new device instance for unitary controller 14 may equal “D_G+(M_G−120)*100+M₁=1001”. The new device instance for unitary controller 15 may equal “D_G+(M_G−120)*100+M₂=1002”. Other new device instances, which follow in the same manner, may equal 1003, 1004 . . . 1000+n, where n is a total number of unitary controllers on line or network 13.
The network needs to be configured as in the following. First, global controllers that are to support auto-addressing should have, for example, an MS/TP MAC address in the range 120-127. The unitaries may look for an “I-Am” message from MAC address 120-127 to determine what their own device instances should be. Not having any device with an MS/TP MAC address in the range 120-127 effectively disables the feature for that MS/TP network.
Second, unitary controllers that support this feature will not communicate if they have a MAC address in the range 120-127. Having a MAC address in the range 120-127 effectively disables the device's MS/TP. This should prevent an auto-addressing device from scrambling the others' device instances. In either case, MAC addresses for the unitaries may be limited to the range 1 . . . 119 and the MAC addresses for the globals may be limited to the range 120 . . . 127. The MAC address 0 cannot be used for anything because it results in no offset from the global. Other numbers or ranges of numbers may be used in MAC addresses for the unitaries and the globals.
Third, global controllers must be addressed such that there is “room” for the unitary device instances. This means that the globals could be addressed 100, 200, 300, and so on, and support up to 99 unitaries. Technically, the globals could be spaced at 200, 400, 600, and so on, and support up to 127 unitaries. In many practical situations, the spacing may range from 50 to 300. Since it is recommended not to go over 80 unitaries per MS/TP, spacing globals in intervals of 100 should be fine.
Some engineers may prefer to prefix the unitary device instance with the global device instance. For example, device 100 may be the router to unitaries 100001, 100002, 100003, and so on. One can get a very similar result by addressing globals with instances 100000, 200000, and so on. The only difference here is that the globals have large numbers rather than the smaller numbers in the 100's.
Global controllers with multiple MS/TP networks need to be configured such that a global controller has a different MAC address on each of the MS/TP networks. This separates the ranges of the devices.
The approach may work as noted in the following. Auto addressing may occur when a unitary listens to an “I-Am” message coming from a global controller. When the global controller emits a device instance that is different from what the unitary has stored in flash, the unitary may update its own copy and re-address itself. In systems with such devices, auto-addressing may be forced by doing anything that causes the global to emit an “I-Am” message.
In the present specification, some of the matter may be of a hypothetical or prophetic nature although stated in another manner or tense.
Although the invention has been described with respect to at least one illustrative example, many variations and modifications will become apparent to those skilled in the art upon reading the present specification. It is therefore the intention that the appended claims be interpreted as broadly as possible in view of the prior art to include all such variations and modifications.

Claims

What is claimed is:

1. A method for setting a device instance setting of a unitary controller, comprising:

receiving via a network port of a unitary controller a global controller identifier;

setting the device instance setting of the unitary controller to a device instance that is based, at least in part, on the received global controller identifier; and

using the device instance setting when subsequently communicating on a building control network via the network port of the unitary controller.

2. The method of claim 1, wherein the unitary controller has a default device instance, and wherein the setting step sets the device instance setting of the unitary controller to a device instance that is based, at least in part, on the received global controller identifier and the default device instance.

3. The method of claim 2, wherein the default device instance comprises a MAC address.

4. The method of claim 2, further comprising:

receiving via the network port of the unitary controller a global controller MAC address; and

wherein the device instance is set based, at least in part, on the received global controller identifier, the default device instance, and the received global controller MAC address.

5. The method of claim 1, wherein the device instance setting is stored in a flash memory of the unitary controller, and the setting step updates the device instance setting in the flash memory.

6. The method of claim 1, further comprising:

wherein the device instance is set based, at least in part, on the received global controller identifier and the received global controller MAC address.

7. The method of claim 1, wherein the global controller identifier is provided by a global controller via the building control network.

8. The method of claim 1, wherein the network port of a unitary controller communicates using a BACnet master-slave/token-passing protocol.

9. The method of claim 1, wherein the global controller identifier is provided by a router via the building control network.

10. A control unit for use in a building automation system, comprising:

a network port for communicating on a building control network;

a non-volatile memory for storing a device instance setting, wherein the device instance setting is used as a network address for the control unit when communicating on the building control network;

a controller coupled to the network port and non-volatile memory, the controller configured to:

receive via the network port a global controller identifier;

set the device instance setting in the non-volatile memory to a device instance that is based, at least in part, on the received global controller identifier; and

use the device instance setting when subsequently communicating on the building control network via the network port.

11. The control unit of claim 10, wherein the control unit has a default device instance, and wherein the controller of the control unit is configured to set the device instance setting in the non-volatile memory to a device instance that is based, at least in part, on the received global controller identifier and the default device instance.

12. The control unit of claim 11, wherein the default device instance comprises a MAC address.

13. The control unit of claim 11, wherein the controller is further configured to:

receive via the network port a global controller MAC address; and

set the device instance based, at least in part, on the received global controller identifier, the default device instance, and the received global controller MAC address.

14. The control unit of claim 10, wherein the controller is further configured to:

receive via the network port a global controller MAC address; and

set the device instance based, at least in part, on the received global controller identifier and the received global controller MAC address.

15. The control unit of claim 10, wherein the global controller identifier is provided by a global controller via the building control network.

16. The control unit of claim 10, wherein the network port is configured to communicate using a BACnet master-slave/token-passing protocol.

17. The control unit of claim 10, wherein the global controller identifier is provided by a router via the building control network.

18. A control unit for use in a building automation system, comprising:

a network port for communicating on a building control network; and

a controller coupled to the network port, the controller configured to receive a seed value via the network port and to self-generate a unique device instance setting that is based on the seed value, wherein the unique device instance setting is used as a network address for the control unit when subsequently communicating on the building control network.

19. The control unit of claim 18, wherein the seed value comprises a global controller identifier that is provided by a global controller on the building control network.

20. The control unit of claim 18, wherein the controller is configured to self-generate the unique device instance setting based, at least in part, on the seed value and a locally stored default device instance.