ســــــــــــلام به همه دوستان،
قسمت دوم BACnet (کنترل هوشمند ساختمان) رو واستون گذاشتم.
Building Wide-Area Networks with BACnet® (Part 2)
By Bill Swan, Alerton
Annex J BACnet/IP devices are designed to provide the way for BACnet systems to grow beyond building-wide or campus-wide internetworks. The author discusses how these new devices can help create systems that cover entire regions and even continents.
EDITOR'S NOTE: Last month the author provided a look at the need and means for constructing wide-area building networks. Discussed were Annex H.3 PAD devices, which can connect distant BACnet building networks together over wide-area Internet Protocol (IP) internetworks by enclosing BACnet messages within IP frames for transport across the IP internetworks. Introduced was the concept of virtual networks, formed when PAD devices communicate across IP internetworks. In this second and final installment, the author examines Annex J BACnet/IP devices.
Annex H.3 PAD devices are the simplest way to connect BACnet networks over Internet Protocol (IP) internetworks, but they have a few limitations. One is that devices are not easily added or removed; the table of peer PAD devices must be changed in every PAD when the configuration changes.
For this reason and others, the IP Working Group of ASHRAE's BACnet Standing Committee (SSPC 135) developed a more extensive protocol, called "BACnet/IP," for connecting BACnet networks over IP internets. Devices incorporating this protocol are known as "Annex J" devices because this protocol has been added to the BACnet standard as Annex J.1
BACnet/IP is able to handle the transport of BACnet broadcasts over IP more efficiently than PAD devices; it allows devices to enter into the system from anywhere in the IP internetwork, and it supports "native IP" BACnet devices - devices such as unitary controllers which send and receive BACnet messages within IP frames instead of BACnet frames, effectively using IP internetworks, even wide-area internetworks, as BACnet local area networks (LANs).
Annex J defines a virtual network, called a "BACnet/IP network," similar to the virtual network used by PAD devices. This virtual network is comprised of a group of devices that communicate among themselves using the BACnet/IP protocol.
BACnet/IP devices may reside on different physical networks that are part of a larger IP internetwork, connected only by IP routers. Unlike PAD devices, BACnet/IP devices in the same virtual network may also be connected to the same physical network.
An aspect of IP used by Annex J is the combination of IP with other protocols to convey messages from one device to another across the internetwork. TCP/IP is the best known, though somewhat complex, combination. It works much like a telephone call: a connection is requested, established, and then bi-directional communications follows.
The simpler - but not as well known - protocol UDP/IP is used by both Annex H.3 PADs and Annex J BACnet/IP devices. It works like mail (or e-mail): a single message is sent off to a destination address without verification of delivery (at this) level).
UDP is an extremely simple protocol. It does little more than provide a 2-byte number, called a "UDP port," that informs the receiving system what message or protocol follows within the UDP/IP frame. The UDP port number 47808 (in hexadecimal, X'BAC0') identifies BACnet messages and is the UDP port used by PAD devices. BACnet/IP devices use this UDP port by default but may be configured to use a different number if necessary. Figure 1 shows the structure of a BACnet/IP message.
BACnet/IP devices scattered around an IP internetwork communicate directly with each other when reading data values, transferring files, or other direct device-to-device communications. They need some assistance, though, in sending BACnet broadcast messages, such as the BACnet "Who-Is" request2, over IP internetworks because IP networks do not as a rule allow BACnet-style "global broadcasts" (that is, broadcasts received by every device everywhere on the internetwork).
Broadcasting is an effective means for getting messages to many devices at once. However, experience has shown that in large internetworks, broadcasts can overwhelm devices because every broadcast message is processed by every device that receives it. For this reason, network administrators normally disallow global broadcasts.
Broadcasts are allowed, but as a rule are restricted to "IP subnets3." (Note: Discussion of IP subnets is beyond the scope of this article, but it is helpful and fairly accurate to consider a broadcast as being restricted to an individual network.) The problem to be solved is how to deliver the global broadcast BACnet messages to all BACnet/IP devices on all subnets in the virtual network.
The IP Working Group developed two solutions to this problem and defined them in Annex J. The first is called "multicasting," and the second is called a "BACnet/IP Broadcast Management Device" (BBMD).
FIGURE 1: Structure of a BACnet/IP message.
Multicasting uses a special kind of broadcast that only designated devices will receive, thus avoiding the burden placed by normal broadcasts on all the rest of devices on the internetwork. A multicast message has a special form of destination address called a "multicast address." IP multicast addresses are in the range from 184.108.40.206 through 220.127.116.11.
A multicast message is transmitted throughout the internetwork but it is only received and processed by devices configured to receive messages sent to that particular multicast address. (Of course, they also receive messages sent to their own individual IP addresses.)
Multicasting has its disadvantages, though. Network administrators sometimes prohibit its use, IP routers usually need to be configured to forward the multicast messages, and support for multicasting is optional for BACnet/IP devices. There should also be consideration for the time when new and different devices are added to a system because BACnet/IP devices that use multicasting cannot be on the same subnet with devices that do not use multicasting.
FIGURE 2: BACnet/IP router.
The BBMD directly forwards a BACnet broadcast message initiated by a BACnet/IP device on its subnet to the other subnets with BACnet/IP devices. Upon arrival at a destination subnet, the message is then broadcast on that subnet.
There are two methods available to the BBMD to broadcast a message on a remote subnet. In the "directed broadcast" or "one-hop" method, the message has a destination address which causes the IP router to the destination subnet to broadcast the message on that subnet. If the router will not perform that broadcast, the "two-hop" method must be used. Here the message to be broadcast is sent to the peer BBMD on the destination subnet. The peer BBMD then broadcasts the message on its subnet. Figure 2 shows both methods in Virtual Network #2.
Every subnet with BACnet/IP devices must have a BBMD in order for broadcasts from devices on that subnet to reach the rest of the BACnet/IP devices in the virtual network.
The BBMD keeps a table, called a "Broadcast Distribution Table," which lists all the BBMDs, including itself, in the virtual network. This table, identical in all the BBMDs of a virtual network, also tells which broadcast method, one-hop or two-hop, is to be used in each destination subnet.
The BBMD does not need to be a physically distinct device. Like the PAD, it can be integrated into a device that performs other operations, such as a building controller.
FIGURE 3: Routing between BACnet/IP networks with BBMDs.
BBMDs also solve the problem of forwarding BACnet broadcasts to devices, such as an operators' laptop workstation, that might attach to the IP internetwork on subnets that do not have BBMDs or multicast routing. The means by which these devices arrange to receive the broadcasts is called "foreign registration."
In foreign registration, the "foreign device" (which is the device that wishes to receive BACnet broadcasts) sends a request to a BBMD. It will then receive copies of the forwarded BACnet broadcasts for a specified time, extending that time by periodic (automatic) renewal requests.
Non-broadcast communications (such as file transfers or reading and writing data values) between the foreign device and BACnet/IP devices are conducted directly, without BBMD assistance.
A BBMD may even be necessary in a multicasting installation. If a remote device that does not support multicasting is to connect to the system, or if it is to connect from a part of the internetwork where multicast messages are not routed, in order to receive broadcasts it must register with a BBMD that supports multicasting and that is located somewhere in the internetwork where multicast messages are routed.