A Performance Analysis of BACnet[R] local area networks.
Advanced building automation systems require real-time monitoring and control of building facilities. In order to manage building systems efficiently, a wide variety of building-related information needs to be collected, stored, and analyzed. As the demands on building facilities and services have increased, the use of distributed, microprocessor-based control systems has become widespread (Newman 1994). Digital communication networks have become a core technology in advanced building automation systems.
In a networked building automation system, many kinds of monitoring, control, maintenance, and management data are transmitted through the network. If network-induced delay of the delivery of these data exceeds practical limits, building automation systems that require real-time control and operation cannot satisfy their performance and functional requirements. Thus, building automation system designers benefit from understanding the performance characteristics of the networks installed in their buildings.
BACnet[R] (Building Automation and Control networks) is a data communication protocol standard designed specifically for building automation and control systems (ASHRAE 2004). BACnet defines an object-based model of the information that may be exchanged between components of the building automation system and an application layer protocol that is used to access and manipulate this information. It also provides a way to convey the information across a variety of local and wide-area networks that may be interconnected to form an internetwork.
In this study, simulation models of the three most commonly used BACnet local area networks (LANs) were developed. Those LANs are Master-Slave/Token-Passing (MS/TP), ANSI/ATA 878.1 (ARCNET), and ISO-8802-3 (commonly referred-to as "Ethernet"). Using the simulation models, the performance characteristics of each of these BACnet LANs were investigated.
A BRIEF DESCRIPTION OF BACnet
Historically, building automation and control systems have used proprietary communication networks. In this kind of closed system, building automation equipment supplied from different manufacturers could not communicate with each other. Building owners and facility managers were forced to rely on products from a single vendor. Modern building automation and control systems provide a variety of building services, such as heating, ventilating, and air conditioning (HVAC); lighting; fire and life safety systems; security; and vertical transportation. There can be significant safety and operational advantages to integrating these building services through integrated control networks. Closed network systems provide a major barrier to integrated building facilities with the kind of flexibility and expandability that building owners want. In order to solve these problems, ASHRAE developed BACnet.
BACnet defines an object-oriented framework for representing the information that may need to be exchanged between components of the building automation system, and an application layer protocol that is used to access and manipulate this information. It also provides a way to convey the information across a variety of local and wide-area networks that may be interconnected to form an internetwork.
BACnet has a layered protocol architecture based on a collapsed version of the Open Systems Interconnection (OSI) Basic Reference Model (ISO 7498 ). Layers 1, 2, 3, and 7 of the OSI model are used as shown in Figure 1. The common object model and application layer protocol can be used with any of four LAN technologies or a point-to-point (PTP) protocol suitable for dial-up telephone communications. BACnet also provides wide-area networking capability (not shown in Figure 1) by using Internet protocols (IP). The network layer provides a way to combine BACnet networks into an internetwork of arbitrary size and complexity. This allows flexibility in configuring various kinds of network systems, and satisfies real-world requirements of building control systems in terms of speed, throughput, and cost (Bushby 1997).
[FIGURE 1 OMITTED]
BACnet has been adopted as an international standard by the International Organization for Standardization (ISO) and by the European Community (EN ISO 16484-5 ). Many countries in Europe and Asia have also adopted BACnet as a national standard.
DEVELOPMENT OF BACnet SIMULATION MODELS
The most commonly used LANs in BACnet systems are Ethernet, ARCNET, and MS/TP. They were selected for this study because of their popularity. Ethernet is now the most widely used LAN technology in the world and is typically used as a high-speed backbone in building automation systems. ARCNET is also a widely known networking technology. In BACnet systems it is typically used over twisted pair networks with EIA-485 (EIA 1988) signaling. MS/TP is the only networking option that was developed specifically for BACnet. The name comes from the fact that it can be configured as a master/slave network, a peer-to-peer token-passing network, or a mixture of the two.
Communication networks such as MS/TP, ARCNET, and Ethernet can be categorized as discrete-event dynamic systems (DEDS) (Casandras and Lafortune 1999). In a DEDS, the state of a system is changed whenever an event occurs, and events occur at random. Some examples of events that can occur in a communication network system include message generation, message transmission, message reception, and many other protocol-specific events, such as message collision, token delivery, polling, etc. In this study, the simulation models were developed using ARENA (Kelton et al. 2001), a tool for developing simulation models of various kinds of DEDS systems.
ARENA provides basic templates for the modeling of DEDS systems. Using the basic templates as a starting point, BACnet-specific LAN models were developed. Figure 2 shows the structure of the simulation models developed in this study. As shown in the figure, the simulation model has three independent modules: the common module, the application layer module, and the LAN protocol module. Users need not modify the whole simulation model when they make a new model for a specific process. Only the modules corresponding to the specific process need to be modified.
[FIGURE 2 OMITTED]
Table 1 shows a brief description of the modules developed for modeling BACnet LANs. The common module provides an interface for users to set the values of all of the simulation parameters. The application layer module generates the request and reply messages of BACnet application services. The messages received by the destination node are used to collect and analyze the statistical information of network-induced delay. Three independent LAN protocol modules were developed, one each for Ethernet, ARCNET, and MS/TP. More details of the simulation model are described in Song et al. (2003).
Table 1. ARENA Modules Developed for Modeling BACnet LANs Module Function Description Simulation Set the simulation time environment and the number of replications Common module Ethernet environment Set the simulation parameters for Ethernet ARCNET environment Set the simulation parameters for ARCNET MSTP environment Set the simulation parameters for MS/TP Application layer Message generation Schedule the generation module of BACnet messages Statistical analysis Collect and analyze statistical information Ethernet node Ethernet node model Hub Ethernet hub model LAN protocol module ARCNET node ARCNET node model Master node MS/TP master node model Slave node MS/TP slave node model
Figure 3 shows a screen capture of the window of an MS/TP protocol simulation model that consists of five nodes. The left pane shows basic templates provided by ARENA. The middle pane shows a simulation model for MS/TP. Using the MSTP_ENVIRONMENT dialog box, various network parameters, such as data rate, propagation delay, timer values, and message length can be set. The dialog window in the figure shows how the simulation parameters are set. The SIMULATION_ENVIRONMENT module is used to set the simulation-related parameters, such as simulation time and the number of replications.
[FIGURE 3 OMITTED]
In the system model, the block named MASTER is a master node model. Node address and the value of some network parameters, such as Nmax_info_frames and Max_Master, can be set using this model. The block named "MASTER_APP" is the application layer model of an MS/TP node. This block generates request and reply messages and calculates statistical information. The block named "M_PACKET" converts the basic ARENA entity to an MS/TP message. Using the M_PACKET module, a user can generate ReadProperty, WriteProperty, ReadPropertyMultiple, UnconfirmedCOVNotification, ConfirmedCOVNotification, or any other BACnet message. The simulation models for ARCNET and Ethernet have a structure similar to the one shown in Figure 3.
PERFORMANCE ANALYSIS OF BACnet LANs
In this section, the performance of MS/TP, ARCNET, and Ethernet is analyzed using their simulation models. In this study, we quantify the offered traffic load of a network as G. The physical meaning of G is defined as a fraction of medium utilization of offered traffic per medium capacity. The variable G includes the frame overhead of the network protocol (i.e., header and trailer in a message frame) but excludes the overhead for medium access management (i.e., token circulation overhead in MS/TP and ARCNET protocols, and message collision overhead in Ethernet). The variable G is expressed as
G = 1/B [N.summation over (I = 1)][[L.sub.i]/[T.sub.i]],
where B is a data transmission rate (bits/s), N is the number of nodes that generate messages in the medium, [T.sub.i] is an average interval of message generation at node i in seconds, and [L.sub.i] is an average message length in bits generated at node i. The variable G has a value between 0 and 1; G approaches 1 as the traffic load offered to the network increases. The delay characteristics of BACnet LANs show different pattern as the network parameters, B, N, [T.sub.i], and [L.sub.i], change. This is because their medium access control algorithms are affected differently by network-induced delay. The variable G is a dimensionless characteristic of the network traffic, and the simulation results can be generalized to other combinations of parameters that result in the same G (see Song et al. 2003). In this study, we analyzed the performance of BACnet LANs with respect to the change of offered traffic load G.
The performance of BACnet LANs is evaluated in terms of service delay. Service delay is defined as the elapsed time to complete one transaction of a BACnet service. For a BACnet confirmed service, the service delay is defined from the instant a request message arrives at the transmitter queue of a client to the instant when a reply message transmitted by its server has completely arrived at the receiver queue of the client. For a BACnet unconfirmed service, the service delay is defined from the instant when a message arrives at the transmitter queue of a sender to the instant when the same message has completely arrived at the receiver queue of a receiver.
Figure 4 shows the structure of client and server nodes in the simulation model. Each node has two processes that run concurrently. A control application process (which is modeled as "MASTER_APP" and "M_PACKET" blocks in Figure 3) generates request messages at time intervals related to the control functionality. A communication process (which is modeled as "RMASTERW" block in Figure 3) that has transmitter queue (Tx Q) and receiver queue (Rx Q) handles frame transmission and reception. A control application process generates its request messages with an average interval of [T.sub.i]. In the ARENA tool described in the previous section, request messages are randomly generated as we specify the corresponding parameters. In Figure 3, messages are generated in the "Create" block, where we specified the corresponding parameters using EXPO(MEAN_TIME). This means that the message generation interval has the exponential distribution (i.e., message generation has the Poisson process) and the value of an average interval of [T.sub.i] is specified in the parameter MEAN_TIME. Figure 4 also shows a sequence of request and reply message transmissions between client and server nodes in a BACnet confirmed service. In a BACnet unconfirmed service, no reply message is transmitted.
[FIGURE 4 OMITTED]
Summary of MS/TP Features
The Master-Slave/Token-Passing (MS/TP) protocol was designed to be implemented using a single-chip microprocessor with a universal asynchronous receiver/transmitter (UART). It uses EIA-485 signaling over a twisted-pair line and is the lowest cost LAN option in BACnet. The name reflects the fact that a MS/TP network can be configured as a master/slave network, a peer-to-peer token passing network, or a mixture of the two. MS/TP supports transmission rates of 9.6, 19.2, 38.4, and 76.8 Kbps.
MS/TP master nodes maintain a cooperative token-passing scheme that regulates access to the medium. The token is circulated from one master node to another, according to a predetermined order based on addresses. A master node that holds the token can transmit up to [N.sub.max_info_frames] messages to either other masters or to slaves before passing the token. [N.sub.max_info_frames] is a network parameter that can be set by the system designer. If there are no more messages to transmit, the node immediately passes the token to the next master node in the token circulation sequence (as we mentioned earlier, this overhead for token circulation is not counted when calculating the offered traffic G). After receiving the token 50 times, a master node transmits a Poll_For_Master frame in order to discover the presence of other master nodes on the network that wish to join the ring. If one is found, it becomes the new successor node in the token ring. If the successor is already the next available address, then this step is omitted.
Slave nodes never hold the token. Slave nodes return a reply only when they receive a request from a master node. A master node that receives a request returns the reply immediately or it may return a Reply_Postponed frame, indicating that the actual reply will be returned at some future time when it holds the token.
Performance Analysis of BACnet Services in MS/TP Networks
This section evaluates the performance of BACnet services over MS/TP networks. Four representative BACnet services, ReadProperty, ReadPropertyMultiple, UnconfirmedCOV-Notification and ConfirmedCOVNotification, were considered, and their average service delays were measured.
In this study, the MS/TP network consists of all master nodes because most of the MS/TP networks currently operated in real buildings are all-master systems. In this analysis, we assume the default transmission rate of MS/TP to be 76.8 Kbps because many MS/TP devices are currently implemented with that speed.
In the ReadProperty service case, the network consists of [N.sub.m] master nodes. We model one node acting as a central controller. The controller node sends a ReadProperty request message one by one in turn to all the other ([N.sub.m] - 1) master nodes. Upon receiving the request message, each master node immediately returns a reply message. In this analysis, the value of [N.sub.max_info_frames] in the central controller was set to 120. Other master nodes do not generate their own message; they just return a reply message. But the token is circulated along other ([N.sub.m] - 1) master nodes before it comes back to the central controller node, and this causes the token circulation overhead.
Message length of request and reply frames is 23 bytes and 29 bytes, respectively, including frame overhead of the MS/TP protocol. Figure 5 shows the resulting average service delays for ReadProperty service requests with respect to the change in the number of nodes [N.sub.m]. As shown in Figure 5, average service delay is sensitive to the number of nodes. This is because the overhead of token circulation is increased as the number of nodes in the medium is increased.
[FIGURE 5 OMITTED]
When the traffic load is low to medium (less than G = 0.7), delay of ReadProperty service is small. This is because the number of messages built up in the transmitter queue of the central controller during one circulation of token along [N.sub.m] nodes is smaller than the value of [N.sub.max_info_frames], and all of them are transmitted when the token arrives. When the traffic load is high, the number of messages built up in the transmitter queue of the central controller exceeds the value of [N.sub.max_info_frames], and the service delay is abruptly increased.
In the analysis of the ReadPropertyMultiple service, the controller node sends a ReadPropertyMultiple request message to all the other nodes. Upon receiving the request message, each node immediately returns a reply message with ten real values. Ten real values were chosen in order to have a message length that would be representative of typical ReadPropertyMultiple requests in operating systems. The message length of request and reply frames is 106 bytes and 175 bytes, respectively, including frame overhead. The simulation results are shown in Figure 6. Compared to the ReadProperty service results in Figure 5, network resources for the ReadPropertyMultiple service are saturated at higher traffic load; thus, the throughput performance is increased.
[FIGURE 6 OMITTED]
Because the message length of request and reply frames is increased in the ReadPropertyMultiple service, for a given G, the message generation interval is reduced. Thus, during one circulation of a token along [N.sub.m] master nodes, fewer messages are built up in the transmitter queue of the central controller compared to the case of the ReadProperty service. The transmitter queue of the central controller is saturated at higher traffic load G. The service delay, however, is slightly higher for the ReadPropertyMultiple service because of the effect of increased message length on transmission time.
In the UnconfirmedCOVNotification service case, one node is designated as a central controller node. All of the other nodes transmit change-of-value (COV) notification messages to the central controller node when a COV occurs. The central controller node does not transmit a reply message. In this simulation analysis, the network also consists of [N.sub.m] master nodes. The token is circulated along the [N.sub.m] master nodes. Because the central controller node does not generate its message, it does not transmit a message even if it captures the token. The other ([N.sub.m] - 1) master nodes transmit their COV notification messages when the token arrives. This causes the token circulation overhead. In this analysis, the value of [N.sub.max_info_frames] in ([N.sub.m] - 1) master nodes was set to 120.
Message length of the UnconfirmedCOVNotification service is 46 bytes including frame overhead. Figure 7 shows the simulation results. The average service delay for Unconfirmed-COVNotification requests is also affected by the number of master nodes because of the token circulation overhead. In contrast with the previous cases of ReadProperty and ReadProperty- Multiple services, the number of master nodes that generate these messages is increased to ([N.sub.m] - 1). The service delay is more severely affected by the token circulation overhead, and the effect of the increment of service delay with respect to the increment of [N.sub.m] becomes greater.
[FIGURE 7 OMITTED]
Like the UnconfirmedCOVNotification case, in the ConfirmedCOVNotification service case, a central controller node receives all of the COV notifications, which are transmitted by the other nodes when a COV occurs. Upon receiving the COV notification message, the central controller node immediately transmits a reply message. Message length of request and reply frames is 48 bytes and 15 bytes, respectively, including frame overhead. Figure 8 shows the simulation results. Comparison with Figure 7 shows that, in an all-master MS/TP network, the difference in service delay between the unconfirmed service and the confirmed service is not significant. The only additional delay for the confirmed service is the transmission delay of the reply message. This is because, in MS/TP networks, the reply is transmitted immediately instead of waiting for the next time the responding node has the token. As expected, network saturation occurs slightly earlier in the ConvfirmedCOVNotification case because of the reply messages.
[FIGURE 8 OMITTED]
Song et al. (2003) investigated the impact of other MS/TP characteristics that cannot typically be changed in an operating system but do have significant implications for product developers.
Summary of ARCNET Features
ARCNET (ATA 1992) is a token passing protocol that supports a range of data transmission rates (156.25 Kbps to 2.5 Mbps) and a variety of network media, including twisted pair, coaxial cable, and fiber optic cable. ARCNET provides faster transmission speeds and more media options than MS/TP. Unlike MS/TP, ARCNET permits a node to transmit only one message when it receives the token even if there is more than one message available in the transmitter queue. Upon receipt of a confirmed request, an ARCNET node must wait for the token before transmitting a reply.
Performance Analysis of BACnet Services in ARCNET Networks
This section evaluates the performance of BACnet services over ARCNET networks. In a manner similar to the analysis described for MS/TP networks, four representative BACnet services, ReadProperty, ReadPropertyMultiple, UnconfirmedCOVNotification, and Confirmed-COVNotification, were considered, and their average service delays were measured. In BACnet systems it is more common to use 156.25 Kbps because it makes use of low-cost twisted pair wiring. In this simulation analysis, a transmission rate of 156.25 Kbps was considered.
In the ReadProperty service case, one node acts as a central controller. Upon capturing the token, the controller node sends a request message to one of the other nodes on the network. A node that receives a request message returns a reply message to the controller node when the receiving node subsequently captures the token. Message length of request and reply frames is 25 bytes and 30 bytes, respectively, including frame overhead of the ARCNET protocol. The simulation results are shown in Figure 9. Due to the effect of token circulation overhead, service delay is sensitive to the number of nodes in the network. By comparing the ARCNET results in Figure 9 with the MS/TP results in Figure 5, it can be seen that the network resource in ARCNET networks saturates at a much lower traffic load G. When the number of nodes in the network is 90, the network becomes saturated even when G is less than 0.07. This indicates that the effect of token circulation overhead in ARCNET networks is greater than in MS/TP networks. This is because ARCNET nodes must always wait for the token before transmitting a reply and only a single message can be transmitted when holding the token.
[FIGURE 9 OMITTED]
The simulation results for ReadPropertyMultiple service requests with ten real values are shown in Figure 10. Message length of request and reply frames is 108 bytes and 177 bytes, respectively, including frame overhead. Comparison with the ReadProperty service delay in Figure 9 indicates that using the ReadPropertyMultiple service increases the throughput of the network because of the reduced effect of token circulation overhead. The performance improvement for ARCNET is much more significant than it was for MS/TP networks (compare Figures 9 and 10 with Figures 5 and 6). Thus, when using ARCNET networks, it is particularly desirable to use the ReadProperty-Multiple service rather than several repetitions of the ReadProperty service.
[FIGURE 10 OMITTED]
Figure 11 shows the simulation results for UnconfirmedCOVNotification service requests. One node is designated as a central controller node. All of the other nodes transmit COV notification messages to the central controller node when a COV occurs. Message length of the UnconfirmedCOVNotification service is 48 bytes, including frame overhead. This service is completed in one token circulation because an unconfirmed service does not require a reply. Because unconfirmed services require only one token circulation, their performance is less affected by the change in the number of nodes. The average service delay is increased abruptly around G = 0.6, and the network resource for UnconfirmedCOVNotification service becomes saturated.
[FIGURE 11 OMITTED]
Figure 12 shows the simulation results for ConfirmedCOVNotification service requests. Like the UnconfirmedCOVNotification case, a central controller node receives all of the COV notifications, which are transmitted by the other nodes when a COV occurs. Upon receiving the COV notification message, the central controller node transmits a reply message. Message lengths of request and reply frames are 50 bytes and 17 bytes, respectively, including frame overhead. A comparison of Figures 11 and 12 shows a significant difference in performance between ConfirmedCOVNotification and UnconfirmedCOVNotification in ARCNET networks. This is because ARCNET nodes must wait for the token before transmitting a reply. In addition, because the central controller node can transmit only one reply message when it captures the token, the reply messages are built up in the transmitter queue of the central controller node, and the service delay increases rapidly. Since most BACnet services are confirmed, ARCNET networks will tend to degrade in throughput more quickly as the number of nodes increase when traffic is high.
[FIGURE 12 OMITTED]
Summary of Ethernet Features
Ethernet is the most widely used LAN technology in the world (Buchanan 1999). Ethernet uses carrier sense multiple access with collision detection (CSMA/CD) (IEEE 1998). On a CSMA/CD network, nodes monitor the network to determine if it is busy. A node wishing to send data waits for an idle condition and then transmits its message. A collision can occur when two nodes transmit at the same time; thus, nodes must monitor the network when they transmit. When a collision happens, both nodes stop transmitting frames and transmit a jamming signal. This informs all nodes on the network that a collision has occurred. Each of the nodes then waits a random period (back off) before attempting a retransmission. Nodes thus contend for the network and are not guaranteed access to it. Collisions generally slow down the network. Each node on the network must be able to detect collisions and must be capable of transmitting and receiving simultaneously. Ethernet transmission rates are 10 Mbps, 100 Mbps, or 1 Gbps. A variety of media can be used, including coaxial cable, twisted-pair, and fiber optics. BACnet allows any of these options and permits them to be combined.
Performance Analysis of BACnet Services in Ethernet Networks
This section evaluates the performance of BACnet services over Ethernet networks. In real applications, traffic generation patterns in Ethernet can be different from that in MS/TP or ARCNET. This is because it is more common for building automation devices on a backbone Ethernet network to generate their own traffic independently rather than having communication with a supervisory controller dominate the traffic, as often happens on other LANs. However, the objective of this study is to investigate and compare the characteristics of network-induced delay in each BACnet LAN protocol. The same four representative BACnet services used with the other network technologies were simulated: ReadProperty, ReadPropertyMultiple, UnconfirmedCOVNotification, and ConfirmedCOV-Notification. In addition, the average service delay of the AtomicWriteFile service was measured because Ethernet is often used as a backbone network. The data rate used in these Ethernet simulations was 10 Mbps.
In the ReadProperty service simulation, one node acts as a central controller node. The node sends a request message to the other nodes in the network whenever it is ready in the transmitter queue. The message may experience a collision before being delivered to its destination node. A node that receives a request message returns a reply message. It may also experience collision. Message length of request and reply frames is 72 bytes, including the Ethernet frame overhead. The simulation results are shown in Figure 13. In Ethernet networks, the number of message collisions increases as the traffic load is increased. Figure 13 shows that the service delay suddenly begins to increase when traffic load G crosses over 0.3. Comparison with the results in Figure 9 shows that ARCNET networks saturate at a lower value of G than Ethernet networks when the number of nodes increases. This is because token overhead increases with the number of nodes in ARCNET, but collisions are a function of message generation rate instead of the number of nodes.
[FIGURE 13 OMITTED]
Figure 14 shows the simulation results for ReadPropertyMultiple service requests with ten Real values. Message length of request and reply frames is 121 bytes and 190 bytes, respectively, including frame overhead. Compared to the ReadProperty service in Figure 13, the Read-PropertyMultiple service increases the throughput of the network system just as it did for the other network technologies. Comparison with the results from ARCNET in Figure 10 shows that the average service delay for Ethernet networks is smaller at light traffic loads, but that Ethernet is saturated at a lower value of G. This illustrates that CMSA/CD is faster at low traffic loads because it does not have token management overhead. As the traffic load increases, collisions cause the network to reach saturation earlier than with token passing networks.
[FIGURE 14 OMITTED]
Figure 15 shows the simulation results for UnconfirmedCOVNotification service requests. Message length for the UnconfirmedCOVNotification service is 72 bytes, including frame overhead. Similar to the MS/TP and ARCNET networks, all the nodes in the medium transmit COV notification messages to a central controller node when a COV occurs. Service delay begins to increase when G is greater than 0.4.
[FIGURE 15 OMITTED]
Figure 16 shows the simulation results for the ConfirmedCOVNotification service. Like the UnconfirmedCOVNotification case, a central controller node receives all of the COV notifications, which are transmitted by the other nodes when a COV occurs. Upon receiving the COV notification message, the central controller node transmits a reply message. The message length of request and reply frames is 72 bytes, including frame overhead. Compared with the unconfirmed service in Figure 15, the service delay for the confirmed service is larger, and it increases more abruptly. Comparison with the results from ARCNET in Figure 12 shows, once again, that the network resource for ConfirmedCOVNotification service in Ethernet is saturated at higher values of G when the number of nodes increases.
[FIGURE 16 OMITTED]
Most building automation and control system architectures use Ethernet as a backbone network. In this section, performance of the service delay for AtomicWriteFile service on Ethernet networks is investigated. AtomicWriteFile was chosen as a way to represent the impact of large message sizes. In this simulation, the message length for a file is assumed to be the maximum length of an Ethernet packet. The message length of request and reply frames is 1503 bytes and 72 bytes, respectively, including frame overhead. Figure 17 shows the simulation result and that the service delay increases exponentially as the traffic load is increased. The AtomicWriteFile service delay is not significantly affected by a change in the number of nodes.
[FIGURE 17 OMITTED]
A building automation system cannot satisfy the requirement of real-time operation if the network-induced delay exceeds the application requirements. This study examined the delay characteristics of three popular BACnet LANs: MS/TP, ARCNET, and Ethernet. Simulations were made using a selection of BACnet messages that represent confirmed and unconfirmed services, and offered traffic load that varies from low to high.
The main criteria to evaluate the performance of LANs are delay and throughput. Throughput is identical to the offered traffic G when the network system is not saturated. The simulation results presented in this paper also should be interpreted in terms of delay and throughput. The reader should keep in mind that the fact that one LAN saturates at higher G does not imply that the LAN is better than others. Service delay and other factors can also be important and should be considered along with throughput.
MS/TP provides simple and low-cost means of communication. Using the ReadPropertyMultiple service to retrieve multiple data values instead of repeated use of the ReadProperty service significantly increases throughput performance but slightly increases the service delay. In all-master MS/TP networks, the difference in service delay between the UnconfirmedCOVNotification and ConfirmedCOVNotification was found to be negligible. Even though MS/TP networks are relatively slow, they are quite efficient for BACnet application services. This is because a capability of immediate reply to confirmed services and the ability to transmit more than one message when holding the token are features well suited to the client/server communication nature of building automation systems.
ARCNET provides faster communication speeds than MS/TP. For ReadProperty service requests, the network resource in ARCNET networks saturates at a much lower traffic load than in MS/TP when MaxInfoFrames for MS/TP is larger than the rate of packet generation. With ARCNET, using the ReadPropertyMultiple service rather than several repetitions of the Read- Property service can significantly increase network utilization. The delay for Unconfirmed-COVNotification in ARCNET is less affected by the token overhead. The delay for the ConfirmedCOVNotification service, in ARCNET, is significantly affected by the token overhead, and the performance is degraded compared to the UnconfirmedCOVNotification service. ARCNET is faster than MS/TP but, because the effect of token circulation overhead is greater for ARCNET, the network performance degrades at lower traffic levels than MS/TP. Both MS/TP and ARCNET are suitable for a LAN that requires real-time communication because they are operated on token-passing discipline.
Because of its cost, Ethernet is usually only used as a backbone LAN in building automation systems. Its high data transmission rate makes it well suited for that application. Compared to ARCNET, the service delay in Ethernet is less affected by the change of the number of nodes. Compared to ARCNET, the delay characteristics of Ethernet are more randomized with respect to the traffic change. Compared to ARCNET, the network resource for ReadProperty service in Ethernet is saturated at higher traffic load, especially when the number of nodes in the network is larger. Using the ReadPropertyMultiple service in Ethernet increases the throughput of the network system just as it did for the other network technologies. The network resource for UnconfirmedCOVNotification and ConfirmedCOVNotification services in Ethernet begins to saturate as G > 0.4. The rate of the increase in service delay for ConfirmedCOVNotification is higher than that for UnconfirmedCOVNotification. Although Ethernet is very efficient at low traffic load, protocol overhead caused by contention is increased as the traffic load is increased. At a heavy traffic load, it may not be able to guarantee the real-time requirements. This is an important consideration if the network is also used to serve business applications or carry other traffic unrelated to the building automation system. However these collision effects might be largely mitigated by the use of Ethernet switches rather than hubs.
This paper presents the characteristics of the service delay of MS/TP, ARCNET, and Ethernet when they deliver BACnet services. In Song et al. (2003), more details of the performance characteristics of three representative BACnet LANs are described. The report includes the effect of the change of MS/TP network parameters on the performance of single-master and multi-master MS/TP networks. It also presents the performance characteristics of transmission delay in ARC- NET and Ethernet. The effect of processing time for BACnet application services in the application and user layers on the performance of service delay is also reported.
The simulation results obtained from this study can provide some guidelines for designing BACnet networks used in building automation systems. In particular, the results provide insight into characteristics that can be used to help select the appropriate LAN and operating constraints that must be met to remain within acceptable service delay limits.
This work was partially supported by the grant from the Basic Research Program of the Ubiquitous Sensor Network Research Center (USNRC) funded by the Gyeounggi Regional Research Center (GRRC) plan.
ASHRAE. 2004. ANSI/ASHRAE Standard 135-2004, BACnet: A Data Communication Protocol for Building Automation and Control Networks. Atlanta: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.
ATA. 1992. ANSI/ATA 878.1-1992, Local Area Network: Token Bus (2.5 MBPS). ARCNET Trade Association.
Buchanan, B. 1999. Handbook of Data Communication and Networks, pp. 497. Boston: Kluwer Academic Publishers.
Bushby, S.T. 1997. BACnet: A standard communication infrastructure for intelligent buildings. Automation in Construction 6(5-6):529-40.
Casandras, C.G., and S. Lafortune. 1999. Introduction to Discrete Event Systems. Boston: Kluwer Academic Publishers.
EIA. 2003. ANSI/EIA/TIA-485-A-1998 (R2003), Standard for Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems. Arlington, VA: Electronic Industries Alliance.
EN ISO. 2003. EN ISO 16484-5, Building Automation and Control Systems--Part 5 Data Communication Protocol. Geneva: International Organization for Standardization.
IEEE. 1998. ANSI/IEEE 802.3-1998, Local Area Networks--Carrier Sense Multiple Access With Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. Piscataway, NJ: Institute of Electrical and Electronic Engineers.
ISO. 1984. ISO 7498, Information processing systems--Open Systems Interconnection--Basic Reference Model. International Organization for Standardization.
Kelton, W.D., R.P. Sadowski, and D.A. Sadowski. 2001. Simulation with ARENA. Boston: McGraw Hill.
Newman, H.M.1994. Direct Digital Control of Building Systems: Theory and Practice. New York: John Wiley & Sons, Inc.
Song, W.S., S.H. Hong, and S.T. Bushby. 2003. A simulation analysis of BACnet local area networks. NISTIR 7038. National Institute of Standards and Technology, Gaithersburg, MD.
Received May 10, 2006; accepted July 17, 2007
Won Seok Song, PhD Seung Ho Hong, PhD Steven T. Bushby Member ASHRAE
Won Seok Song is a senior researcher in the R&D Center, I-Controls, Inc., Seongnam, Korea. Seung Ho Hong is a professor in the School of Electrical and Computer Engineering, Hanyang University, Ansan, Korea. Steven T. Bushby is a leader in the Mechanical Systems and Controls Group, Building and Fire Research Laboratory, National Institute of Standards and Technology, Gaithersburg, MD.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Building Automation and Control networks|
|Author:||Song, Won Seok; Hong, Seung Ho; Bushby, Steven T.|
|Publication:||HVAC & R Research|
|Article Type:||Technical report|
|Date:||Mar 1, 2008|
|Previous Article:||The effect of membrane deflections on flow rate in crossflow air-to-air exchangers.|
|Next Article:||Dynamic behavior of mobile air-conditioning systems.|