BACnet

[seyed mehdi hoseyni 27,119]

[h=1]Building Wide-Area Networks with BACnet® (Part 1)[/h]

By Bill Swan, Alerton

There are devices and methods by which BACnet networks can be interconnected over Internet Protocol, wide-area networks. The first of two parts, this article looks at network basics, the use of IP internets to connect systems, and BACnet/IP PAD devices.

New technologies create demands for new capabilities. BACnet is no exception.

Initially envisioned as a building-wide network protocol, BACnet (ANSI/ASHRAE Standard 135-1995, Building Automation Control Network) is now being used to join buildings together on campus-wide internetworks. And there is increasing demand to interconnect BACnet systems across cities, regions, countries, and even continents.

In nearly all cases, the desire is to use an existing Internet Protocol (IP), wide-area network (WAN) already spanning the area to join the BACnet systems. However, BACnet devices and IP devices speak different protocols, different languages; one cannot simply plug them into the same network and expect them to work.

Special devices are required in order for BACnet messages to be transported across IP networks to BACnet devices in distant locations. These devices, described in the standard, are already in use.

Last year, for instance, BACnet networks at the Phillip Burton Federal Building (San Francisco), Cornell University (Ithaca, NY), and the National Institute of Standards and Technology (Gaithersburg, MD) were all joined together over the Internet, in a public demonstration of a very wide area BACnet system indeed.

The following is a look at the devices and methods by which BACnet networks are interconnected over IP WANs.

[h=2]INTERNETWORKING AND ROUTERS[/h]

It is often necessary to set up multiple networks to communicate with each other. This may be required because different network types with different characteristics are being used.

For example, Ethernet, which is frequently used in building automation systems (bas), works well as a building-wide network, but it cannot span a continent. Other network technologies must be used for such long distances. Thus, multiple networks must be used if buildings in distant locations are to be joined in a single system.

For multiple networks to communicate, there must be a common language or protocol used by the devices on those networks. For BACnet devices, the protocol is BACnet.¹ For IP networks, of course, it is the underlying protocol used by the Internet itself, as well as by many private networks.

The protocol defines the format of the message packets exchanged between devices. It also defines the format of the message frame, the surrounding envelope that determines what destination address should be used, and what protocol the frame is using.

Some protocols, such as BACnet, define the entire frame and packet together. Other protocols, such as IP, can state within the frame that a different protocol is to be used to decode the packet within.

When multiple networks using the same protocol for their packets are joined, the result is called an internetwork.² (It is also called an "internet," but that term is too easily confused with the Internet, the best-known internetwork.) Internetworks can also be created with multiple networks using different protocols if a device called a protocol converter, also known as a gateway, is used to translate the messages going back and forth.

The devices that join the networks of an internetwork are known as routers. Unlike most devices that connect to a single network, routers connect to two or more networks for the purpose of forwarding messages sent by a device on one network and destined for a device on another network.

In complex internetworks, a message may have to be forwarded through several routers and across several networks before reaching its destination.

A router must be able to understand the frame's protocol in order to determine whether or not a message is destined for another network. If the message is destined for a device on the same network, the router must not pass it on; doing so would flood the rest of the internetwork with extraneous messages. Thus, BACnet routers must understand BACnet frames and IP routers must understand IP frames.

BACnet internetworks that are connected only by routers that understand BACnet frames are defined here as directly connected internetworks. (In Figure 1, networks 102 and 103, but not 101, comprise a directly connected internetwork.) This distinguishes them from the super-internetworks, serving to join multiple directly connected internetworks, which can be created by devices that allow BACnet packets to be carried within IP frames

 

 

 

 

[h=2]THE PROBLEM AND ITS SOLUTIONS [/h]

The problem one encounters when trying to connect the component BACnet networks (or directly connected BACnet internetworks) of a wide-area BACnet internetwork together over an IP wide-area network, is that IP routers do not understand BACnet frames.

If an IP router has a connection to a BACnet network and receives a BACnet frame that needs to be delivered to another network, it will do...nothing.³

The problem is solved with special kinds of BACnet devices that also understand the IP protocol. Such a device is able to take a BACnet message and enclose it within an IP frame that an IP router can read and deliver across an IP internetwork.

At the destination, another such BACnet device extracts the BACnet message from the IP frame, reads it, and forwards it if necessary.

Annex H.3 of the original BACnet standard describes this technique known as "tunneling," by which devices called B/IP PADs (BACnet/Internet-Protocol Packet-Assemblers-Disassemblers), also known as Annex H.3 devices, act like routers to transport BACnet messages across IP internetworks.

A recent addition to the BACnet standard, Annex J-BACnet/IP, describes a flexible extension of the original concept. It even includes descriptions of BACnet/IP devices that always enclose their BACnet messages within IP frames.

[h=2]BACNET/IP PADS [/h]

To connect BACnet networks over IP networks, a special kind of router called a BACnet/IP PAD (BACnet/Internet-Protocol Packet-Assembler-Disassembler) is placed on every BACnet network (or directly connected internetwork) that is to be connected over an IP network to another BACnet network. The PAD need not be a physically distinct device; it can be part of a device that performs other operations, such as a building controller.

The PAD acts like a BACnet router. When it receives a BACnet message destined for a distant BACnet network, a network reachable only through an IP internetwork, it wraps the message inside an IP frame, gives the frame the destination IP address of the corresponding PAD on the destination BACnet network, and sends the frame on its way over the IP network.

The receiving PAD removes the BACnet message from its IP frame and transmits the message to the destination device on the local LAN, just as if it had come from a BACnet router.

The BACnet devices originating and receiving the messages are unaware of the special operations used to deliver the messages. They communicate with the PADs as if the PADs were ordinary BACnet routers connecting BACnet networks.

Two configurations of PADs exist, as shown in Figure 1. The first has a single physical network connection, or port, typically to an Ethernet network, through which both BACnet and IP frames are transmitted and received.

It requires an IP router to be connected to this network in order to have its IP frames delivered to the distant PAD. (The PAD may also have other BACnet-only ports.)

The second PAD configuration has different ports for BACnet and IP frames. The IP port may thus be directly on the IP internetwork connecting the BACnet networks. Typically, the PAD appears to the IP internetwork as a device communicating using IP, not as an IP router.

[h=2]VIRTUAL NETWORKS [/h]

Depending upon the implementation, a set of intercommunicating PADs can look to devices on the BACnet networks like a single physical router with a port on each of the BACnet networks to which it is connected.

The IP routers and networks that participate in the communications are completely invisible to the BACnet devices.

 

 

In a different implementation, the PAD devices will instead appear to the BACnet networks as BACnet routers directly connected by a single network. This network is called a "virtual network" because it will usually be an internetwork composed of multiple IP networks instead of a single physical network.

 

Figure 1 shows the physical implementation of such an internetwork. Figure 2 shows the internetwork, including the virtual network, as it appears to the BACnet devices.

 

One significant difference between PADs and other BACnet routers is the way global (internetwork-wide) broadcasts are handled. Other routers rebroadcast the message on all networks other than the one the message came from, but a PAD sends a separate IP frame to each of its peer PADs.

 

This avoids the use of broadcast IP frames, a practice frowned upon by many network administrators. It also requires that the PAD keep a table of its peers' IP addresses.

 

Careful attention must be paid to certain BACnet rules when constructing a wide-area BACnet internetwork. Parameters that are required to be unique across a BACnet internetwork (such as every device object's Object Identifier, Object Name properties, and network numbers) must remain unique when already-operating networks are subsequently interconnected via a wide-area IP network. Failure to follow this rule is a common source of trouble.

 

One of the most critical BACnet rules to be obeyed is that there must be only one path across the internetwork for BACnet frames to traverse between any two devices. This means there cannot be more than one PAD device connected to a directly connected BACnet internetwork (unless each PAD is on a different virtual network, as explained later).

 

This path restriction does not apply to the IP frames transferred between PADs. There may, for example, be more than one IP router connecting the BACnet network to the IP Internet and basic PAD devices may take advantage of this fact, automatically rerouting their IP frames through the secondary IP router if the primary IP router fails.

CONFIGURING A PAD

 

Configuring a PAD device seems complex because of the number of IP parameters that need to be entered, but in fact, nearly all the parameters should be provided by a network administrator responsible for the IP internetwork. The only non-IP parameter is the BACnet network number to be assigned to the virtual network. Depending upon their implementation, some PADs might not have this parameter.

 

A representative PAD device setup menu is shown in Figure 3. The device menu in Figure 3 shows that PAD devices have fixed (assigned) IP addresses, unlike many devices that can be assigned an IP address automatically upon each startup by a server on the IP network.

 

Although this makes for more work for the network administrators, it is necessary; without fixed addresses, there is currently no means for the B/IP PAD devices to locate each other without broadcasting queries.

 

Figure 4 shows the relationship between a PAD's IP address parameters and the configuration of an actual network. The IP addresses are shown in the common "dotted quad" form: four decimal numbers, each in the range from 0 to 255, separated by periods. These numbers represent the four bytes of the actual IP address.

MULTIPLE VIRTUAL NETWORKS

 

PAD devices will have a limit to the number of other PADs with which they can communicate, due to restrictions on memory and the communications bandwidth. If the PADs will talk to, say at most, 31 other PADS, only 32 directly connected BACnet internetworks can be joined by a single virtual network.

 

This does not place a limit on the total number of BACnet networks that may be joined over IP internets, however. Multiple virtual nets may be constructed and connected to create a "super" virtual internetwork.

 

 

Sometimes it may be desirable to construct multiple virtual networks where the PAD limitations have not been reached. An example is a wide-area BACnet internetwork joining all the buildings of a number of distant campuses. Each building has its own BACnet network, and has access to its campus-wide IP internetwork; each campus IP internetwork is part of a larger IP internetwork joining the campuses. Each campus can be serviced by a single virtual network, but there are far too many buildings for a single virtual network to cover all buildings in all campuses.

In this scenario, it makes sense to construct a separate virtual network within each of the campuses, and a third virtual network joining the campuses. Figure 5 illustrates this implementation in a two-campus internetwork. Each campus has its own IP internetwork with its own virtual network, #1 and #2 (presumably, there are many more networks in each campus than are illustrated). The two campuses are joined by a third virtual network, #10.

 

 

As with the single virtual network, BACnet rules must be observed throughout the entire BACnet internetwork. Only one PAD device from any particular virtual network may be connected to a BACnet directly connected internetwork.

 

Virtual networks must not be connected so that more than one path through BACnet physical or virtual networks exists between any two BACnet devices. Any failure to observe these rules will be immediately evident as internetwork traffic volumes skyrocket, possibly shutting down the networks, and definitely making some network administrator very unhappy.

 

Next month: A look at Annex J BACnet/IP devices.

 

FOOTNOTES

1 See "The Language of BACnet," Engineered Systems, July 1996.

2 See "Internetworking with BACnet", Engineered Systems, January 1997.

3 Some IP Routers can be confgured to pass through any message carrying the code identifying it as a BACnet message, but this can result in the IP internetwork being flooded with BACnet messages.

 

Swan is BACnet specialist at Alerton (Redmond, WA). He can be reached at bills@alerton.com. Swan is secretary of the ASHRAE BACnet Standing Committee, SSPC 135, and serves on an ISO Technical Committee (ISO/TC 205/WG 3) developing an international building automation communications protocol.

 

 

[seyed mehdi hoseyni 27,119]

[h=1]Building Wide-Area Networks with BACnet® (Part 2)[/h] 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).

[h=2]BACNET/IP NETWORKS[/h] 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.

[h=2]BROADCAST MANAGEMENT[/h] 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" request², 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).

 

 

 

 

MULTICASTING

 

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 224.0.0.0 through 239.255.255.255.

 

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.

 

 

 

 

 

BBMDs

 

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.

 

 

 

FOREIGN DEVICES

 

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.

 

 

 

 

[h=2]MULTIPLE NETWORKS AND BACNET/IP ROUTERS [/h] It is possible to build a single, very large virtual BACnet network over an IP internetwork. Annex J observes that this may be undesirable for several reasons, including overall traffic volume and system security. In such cases, it is preferable to create multiple BACnet/IP virtual networks and interconnect them into a larger "BACnet/IP internetwork."

To interconnect the BACnet/IP networks, a device called a "BACnet/IP router" is required, as shown in Figure 2. This device has all the capabilities of a standard BACnet router⁴, but it communicates using BACnet/IP frames. In an installation, the BACnet/IP router must also support the broadcast management method in use in the installation, whether multicasting or BBMD forwarding.

If multicasting is being used, each BACnet/IP network should use a different multicast address to carry its BACnet broadcasts.

If BBMD forwarding is being used, the BACnet/IP router has two options for operation. If it incorporates BBMD capabilities as well as routing, it can be included into the Broadcast Distribution Table for each BACnet/IP network. (The BACnet/IP router needs a separate table for each BACnet/IP network to which it is connected.) Otherwise, it must register as a foreign device with a BBMD on each of the BACnet/IP networks. Both configurations are shown in Figure 3.

If the BACnet/IP Router is capable of both BACnet and BACnet/IP communications, and is able to communicate using both BACnet frames and IP frames, it is called a "BACnet-to-BACnet/IP router." It may also be used to route messages between a network of normal BACnet devices and the BACnet/IP internetwork.

[h=2]MIXING BACNET AND BACNET/IP DEVICES [/h] BACnet, BACnet/IP, and PAD devices can all operate together in a BACnet/IP network but three rules must be observed.

The first rule is that BACnet and BACnet/IP devices cannot communicate directly with each other. Their messages must be routed through a BACnet-to-BACnet/IP router, as shown on the bottom network in Figure 4. If both BACnet and BACnet/IP devices exist on the same physical network, such as an Ethernet, that network has two BACnet network numbers: one for the BACnet devices and another for the BACnet/IP devices.

The second rule is that BACnet/IP devices cannot communicate directly with PAD devices. To join BACnet/IP devices to a system using PADs and BACnet devices, a BACnet-to-BACnet/IP router must be on the same directly-connected BACnet internetwork as one of the PADs, as shown in the middle network of Figure 4.

The third rule is that the BACnet requirement of a single path between any two devices is met if the BACnet message does not have more than one path through BACnet and BACnet/IP routers between any two BACnet and BACnet/IP devices.

[h=2]SUMMARY [/h] The rapidly increasing use of wide-area IP internets provides an excellent opportunity to expand the reach of BACnet systems. Annex H.3 PAD devices and Annex J BACnet/IP devices provide the way for BACnet systems to grow beyond building-wide or campus-wide internetworks, to create systems that cover entire cities, regions, countries, and even continents.

 

FOOTNOTES

¹ Annex J, approved as Addendum 135a to the BACnet standard, may be found on the BACnet website at

برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید.

• ورود
• یا
• ثبت نام

.

² See "The Language of BACnet," Engineered Systems, July 1996. "Internetworking with BACnet", Engineered Systems, January 1997.

³ A full explanation of IP addressing ande dsubnets can be found in books on TCP/IP. Another reference is on the Internet at

برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید.

• ورود
• یا
• ثبت نام

⁴ "Internetworking with BACnet", Engineered Systems, January 1997.

Swan is BACnet specialist at Alerton (Redmond, WA). He can be reached at bills@alerton.com. Swan is secretary of the ASHRAE BACnet Standing Committee, SSPC 135, and serves on an ISO Technical Committee (ISO/TC 205/WG 3) developing an international building automation communications protocol