Printer Friendly

Communication performance of BACnet Web Service over the Global Internet.

INTRODUCTION

The BACnet standard (ASHRAE 2004) for building management systems is becoming popular, not only in North America, but also in Asian and European countries. Recently, a new technology for the Internet, "Web Services", has emerged. The BACnet standard has employed Web Services as one of the communication methods for exchanging BACnet messages (ASHRAE 2006). Since the Web Services communication method uses the Internet Web access protocol, i.e., HTTP (HyperText Transfer Protocol), it is possible to pass through firewalls in IP networks. It is expected that BACnet Web Services (BACnet/WS) will become a desirable BACnet communication method for building management systems over the Internet (Tom, S. 2004).

Due to its character-based message format, the BACnet/WS method takes a longer time to transmit a message compared to the conventional BACnet communication methods. Although bit rates of IP networks are increasing, signal propagation delay between extremely long distances, such as inter-continental locations, will not shorten proportionally. The communication performance will still be a significant problem even in the future for BACnet/WS over the Internet.

There have been many research papers on various aspects of the BACnet standard, such as conformance testing (Bushby 1990), communication characteristics (Tomboli 1995; Song 2003), and implementation modeling (Huang 2004). Some research papers have focused on the performance of specific communication methods, i.e., BACnet/MS/TP (Master Slave/Token Passing) (Song 2003; Hong 2003; Hong 2004a; Hong 2004b) and BACnet/IP (Ninagawa 2005). The communication protocols of these methods, i.e., the MS/TP and UDP (User Datagram Protocol) are relatively simple as compared to the TCP protocol (Stevens 1994). Theoretical study of the communication performance of BACnet/WS using TCP for message transmission is difficult because the TCP maintains a complicated algorithm. So far, few research papers on the evaluation of communication performance of the BACnet/WS have been published (Ninagawa 2008).

Even though the BACnet/WS standard was never intended for real-time applications, attention should be paid to transmission delay of BACnet/WS remote systems in the cases of extremely distant networks. In general, remote systems need careful engineering for interactive applications using the Global Internet. Furthermore, the data format and transmission method of BACnet/WS takes a longer message compared to BACnet/IP. Systems designers should predict throughput of BACnet/WS and decide how many objects can be read at once for reasonable response over the Global Internet.

This research has carried out theoretical and experimental studies on the message communication performance of BACnet/WS object access over the Internet. The average transmission times of a "getValues" service for a large number of objects were measured from several inter-continental locations. Padhye's theoretical calculation of a TCP/IP throughput equation (Padhye 2000) has accurately matched field test data from experiments performed for this research.

This research has found that the average BACnet/WS transmission time is roughly proportional to the average round trip time of the "Ping" probing (Stevens 1994) of an IP network. In addition, it is also approximately proportional to the number of objects in a "getValues" service. This paper concludes that the transmission time takes up a significant portion of the total service time of a remote BACnet/WS system over the Internet and will do so in the future.

BACNET/WS SYSTEM

BACnet/WS Remote System

Figure 1 shows a conceptual diagram of a BACnet/WS remote management system for VRF (Variable Refrigerant Flow) air-conditioners over the Internet. VRFs are a type of distributed heat source air-conditioners mainly applied to medium size commercial buildings (Yang, H. 2001; Goetzler 2007). A typical VRF air-conditioning system consists of tens or hundreds of air-conditioner units. Each air-conditioner unit includes a microcomputer controller for autonomous high-level functionality in the air-conditioning system. These controllers exchange control messages with each other using a proprietary VRF fieldbus communication system (Honda 1993; Yokohama 2008). Each high-level functionality, e.g., "OnOffStatus" or "OperationMode" is represented by a BACnet object data structure such as "BinaryInput" or "MultiStateInput" type defined by the BACnet standard. The total number of BACnet objects for a VRF air-conditioning system often reaches more than hundreds.

[FIGURE 1 OMITTED]

All BACnet objects are implemented in a device called a "gateway" (Bushby 1998) in most cases of VRF systems. The gateway is connected with the building management system network and the VRF fieldbus as shown in Figure 1. BACnet's fundamental way of accessing objects is based on a type of "Client-Server" framework. The web server software on the gateway holds the BACnet objects. A number of web clients access the web server on the gateway using BACnet/WS communication method. These clients are not necessarily located in the same building in which the server is located. In the case of the system model in this research, the clients are assumed to be located on different continents and communicate with the server over the Internet.

In actual applications of BACnet/WS to remote management systems, the number of objects read at a single access depends on system design. In this paper, in order to investigate the limitation, we have studied extreme cases of the single access with up to 1000 objects in the BACnet/WS server over various inter-continental connections. This paper focuses on the net communication performance, that is, the total transmission time of this BACnet/WS object request/response access.

Modeling of BACnet/WS Access

Since this research focuses on communication performance, lengthy messages of BACnet/WS services are the primary focus of this paper. This research has selected the "getValues" service defined by the BACnet/WS standard because it is a typical service for reading a number of objects at once in a BACnet/WS remote system and the access often results in a lengthy message.

Figure 2 shows a model of message data transmission of the BACnet "getValues" service. In the "getValues" service, a web client transfers a request message of "getValues" to the web server. Then, the web server returns a response message to the client. The request/response messages are represented by the SOAP (Simple Object Access Protocol) standard, and controlled by the HTTP upper layer protocol. The TCP/IP lower layer protocol divides the message into a number of communication packets and transports them one by one over the IP network. After all the packets of the request message are received by the web server, it reconstructs these packets into the original request message. Next, the server parses the contents of the request message and prepares a corresponding response message. The response message is transferred from the server to the client in the same way as the request message by the TCP/IP protocol.

[FIGURE 2 OMITTED]

It is assumed that the BACnet/WS web server on the gateway has a cache memory for the present values of the BACnet objects representing the high-level functionality states of the air-conditioners so as to return the values immediately. The gateway periodically collects the present values of objects from each air-conditioner unit via the VRF fieldbus. In general, the interval of point value collection is several tens of seconds for cases of VRF building air-conditioning systems.

In this paper, the elapsed time from the moment when the gateway finishes receiving a request message to the moment when it starts sending a response message is defined as the web server process time [T.sub.SP]. In the case that the gateway has the above-mentioned cache memory, [T.sub.SP] is short such as 0.3 s compared to the transmission time over the Internet. The process time [T.sub.SP] hardly depends on the number of objects in one request message in most implementations. Therefore, [T.sub.SP] can be negligible for the Global Internet communication in the case of inter-continental connections.

In this paper, the total access time for a pair of request/response messages is defined as [T.sub.A]. The time [T.sub.A] consists of the request transmission time [T.sub.T1], the web server process time [T.sub.SP], and the response transmission time [T.sub.T2] as shown in Figure 2. Here, the total request/response transmission time [T.sub.T] is defined as [T.sub.T] = [T.sub.T1] + [T.sub.T2]. Hereafter in this paper, the term "transmission time" means [T.sub.T] excluding the process time [T.sub.SP], and [T.sub.T] will be treated as object access time [T.sub.A] unless otherwise stated.

Content of BACnet/WS "getValues" Message

Figure 3 shows the content of a request message for an object access service "getValues". The "getValues" service is one of the service types defined by the BACnet/WS standard. This service type is for requesting the values of a number of objects at once. In the special case that the number of objects is one, the service type is called "getValue".

[FIGURE 3 OMITTED]

In the case of an example shown in Figure 3, the number of objects K is 1000. In this example, there are 1000 blocks of XML (eXtensible Markup Language) data items. Each block corresponds to an instance of the BACnet object on the web server. Each object is able to have a number of properties that hold a specific value representing each air-conditioner's present value. The names of objects and properties are specified by character strings conforming to the XML tag-formatting rule. The XML tag-formatting rule is another cause that makes BACnet/WS message length long in comparison with BACnet/IP.

As mentioned above, the web server of a VRF gateway often has hundreds of objects and the length of the "getValues" message can be more than hundreds of bytes. This makes the message transmission time of the BACnet/WS an important matter when the message data length and the distance over the Internet network are significantly large.

Once the above-mentioned message data is handed over to the TCP/IP lower layer of communication, the message is now merely a stream of character bytes. Therefore, the TCP/IP protocol executes transmission of the BACnet/WS message as just a plain payload, even though the content of the message has a layered structure from the BACnet application software's point of view. Table 1 shows the data length of the BACnet/WS messages in the cases of the "getValue" of one object, "getValues" of 500 objects, and "getValues" of 1000 objects for the above-mentioned example shown in Figure 3.
Table 1. BACnet/WS Message Length Parameters

Parameter                          "getValue"  "getValues"  "getValues"

No. of objects in one access:          1           500         1000
[N.sub.O]

Message length (*1)

 Request message length              1.2 kB      225 kB       449 kB

 Response message length             0.9 kB      115 kB       230 kB

 Total message bytes: [L.sub.MB]     2.1 kB      340 kB       679 kB

Number of packets (*2)

 Request message packets               2           154          309

 Response message packets              1           79           158

 Total message packets: [L.sub.MP]     3           233          467

(*1) Message length from the TCP/IP protocol's point of view.

(*2) Assumed that an IP packet size is 1.460 kB.


It is well known that the number of IP packets [L.sub.MP] for a message to be sent by the TCP/IP is calculated by dividing the message length [L.sub.MB] by the unit IP packet size of 1.460 kB as shown in Table 1. Now that [L.sub.MP] has been obtained, the average transmission time [T.sub.T] for both the request and response messages can be calculated if the average throughput of the TCP/IP data transmission can be derived.

THEORETICAL CALCULATION

Calculation of TCP/IP Transmission Throughput

The number of IP communication packets that successfully arrive at the destination during a unit time is called "throughput" of data transmission. Since TCP/IP data transmission is a complicated stochastic process, the throughput varies each time depending on stochastic network conditions. However, the average throughput of TCP/IP transmission [S.sub.a] is given by the following equations (Padhye 2000).

[MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII] (1)

where W(p), Q(p, w), and G (p) are defined as followings,

W(p) = 2/3 + [(4(1 - p)/(3p) + 4/9).sup.[1/2]] (2)

G(p) = 1 + p + 2[p.sup.2] + 4[p.sup.3] + 8[p.sup.4] + 16[p.sup.5] + 32[p.sup.6] (3)

Q(p, w) = min(1, [(1- [(1 - p).sup.3])(1 + [(1 - p).sup.3](1- [(1 - p).sup.w-3]))]/[1 - [(1 - p).sup.w]]) (4)

The parameters p, [T.sub.RT], [T.sub.O], and [W.sub.m] are the average loss rate of packets, the average round trip time of packets, the timeout for retransmission, and the maximum windows size, respectively. The term "window size" is the number of packets the sender can transmit before receiving the receiver's acknowledgement.

Figure 4 shows an example of the TCP/IP average throughput calculation results plotted with respect to the average loss rate p with parameters of the average round trip time [T.sub.RT]. The window size [W.sub.m] and the timeout [T.sub.O] are assumed to be 10 and 3.0 s, respectively for typical values. As shown in the figure, the throughput [S.sub.a] for various values of [T.sub.RT] becomes saturated for the values of p less than approximately 0.002 (dimensionless). Therefore, in the cases of small values of p the average throughput [S.sub.a] of the BACnet/WS message transmission can be predicted using the parameter [T.sub.RT].

[FIGURE 4 OMITTED]

The average transmission time over the network is calculated by dividing the message length (the number of packets [L.sub.MP]) by the average throughput [S.sub.a] (the number of packets received per second). The transmission time becomes longer for a smaller throughput. In cases that the data transmission time accounts for a large part of the total access time, the total access time is highly dependent on the throughput. If insufficient throughput is known in the stage of commercial operation, the system may have to be redesigned. Therefore, it is important to predict the throughput for the prior evaluation of the response time of the remote screen from a different continent.

THE INTERNET FIELD TEST

The Internet Field Test Method

A gateway testing device with the BACnet/WS web server was placed at a site in Nagoya, a city in Japan. The locations of the BACnet/WS web clients were chosen in such a way that the propagation delays over the Internet were as different as possible. The gateway with the BACnet/WS web server was connected to a broadband router, and then the router was connected to an internet provider. A fixed global IP address was allocated to the gateway testing device. The web server on the gateway was laid open to the Global Internet. In actual commercial operation, a VRF fieldbus would be connected to the gateway. In this field testing, however, no VRF fieldbus was connected for security reasons. Instead, simulation software for the behavior of each air-conditioner unit of a VRF air-conditioning system was installed in the gateway testing device.

The performance of the BACnet/WS transmission over the Internet varies from time to time even in the case of fixed client/server locations. Thus, it is necessary to log many transmission times periodically in order to obtain an average value for stable performance evaluation. The logging software on the web client was developed for this field test.

"Ping" probing is a well-known and widely-used check method for IP network connectivity (Stevens 1994). In the Ping probing, a client sends an ICMP ECHO communication packet to a server and measures the round trip time of the packet transmission. The Ping round trip time represents "degree of distance" from the viewpoint of IP network packet transmission. The Ping round trip time varies significantly from time to time even in the case of the same IP network connection because of the Internet's intrinsic characteristics. While the web client executes and logs data transmission time of "getValues" access, it also probes and logs the Ping round trip time as the reference of IP network "degree of distance" for each specific case.

In this field test, the same personal computer was used for all the web client locations to avoid the influence of using different PCs for the clients. The logging software on the web client was called upon on every hour, and it executed "Ping" probing and "getValues" access to the gateway at the same time. Then, it recorded the "Ping" round trip time and "getValues" access time. The logging period of each client location was 48 hours on weekdays.

The Internet Field Test Results

Figure 5 shows measurements of the field test of the BACnet/WS "getValues" object access from the web clients to the web server over the Internet. The horizontal axis is the "Ping" round trip time [T.sub.RT], and the vertical axis is the access time [T.sub.A] of the "getValues" service. Each pair of [T.sub.A] and [T.sub.RT] of the 48-hour measurements has been plotted in order to form a scattered graph of the access time [T.sub.A].

[FIGURE 5 OMITTED]

In the case of the direct connection, i.e., a client computer is connected with the gateway by a short LAN cable, all measured values of [T.sub.RT] and [T.sub.A] were extremely small. In the case that both client and server are located within Nagoya, Japan, the distribution of the data was still small. In such cases, the transmission time will not be a significant problem, even if the number of objects in a "getValues" access is such a large number as 1000. In the cases of the client locations of Bangkok and London, however, the degree of data distribution was far larger as compared with the cases of direct connection and Nagoya. The measured data of [T.sub.A] for Bangkok and London were distributed within approximately 8-20 s and 14-20 s, respectively. In summary, the transmission times of the "getValues" access for 1000 objects were roughly ten to twenty seconds in the cases of locations on different continents. These transmission times might become a serious problem when a client tries to read hundreds of BACnet objects at once.

Figure 6 shows the total average of the 48-hour measurements [T.sub.RTa] and [T.sub.Aa] for each client's location. In the cases of the direct connection, Nagoya, Bangkok, and London, the results of the average "Ping" round trip time [T.sub.RTa] were 0.001 s, 0.028 s, 0.160 s, and 0.278 s, respectively. Also, the results of the average access time [T.sub.Aa] for the direct connection, Nagoya-city, Bangkok, and London were 0.37 s, 4.2 s, 11.6 s, and 17.1 s, respectively.

[FIGURE 6 OMITTED]

It is reasonable to expect the access time for "getValue" of a single object is smaller than that for "getValues" of plural objects because the message length is roughly proportional to the number of blocks in message data, as shown in Figure 3. As a reference, Figure 7 and 8 show a special case that the BACnet/WS message is extremely short, that is, the number of objects in the "getValues" is one. As shown in Figure 8, the measured average access times [T.sub.Aa] for the direct connection, Nagoya-city, Bangkok and London were 0.02 s, 0.09 s, 0.38 s, and 0.60 s, respectively.

[FIGURE 7 OMITTED]

[FIGURE 8 OMITTED]

Each access time for the "getValue" for only one object is short enough as mentioned above because of a short message length. However, it is necessary for a client to invoke a large number of "getValue" services to collect all object values. The total processing time of a number of the "getValue" single object accesses will be longer than that of one "getValues" plural object access. The reason is that the data byte stream for each "getValues" message has a fixed header part regardless of the number of objects in a "getValues" access. Since this research focuses on the marginal situation of the Internet, hereafter, the number of objects is chosen as an extreme case of 1000 for studying problems of longer transmission times over the Global Internet transmissions.

Comparison between Theoretical Calculation and Field Test

For the cases of network transmission such as the cases of Nagoya, Bangkok, and London, it is possible to calculate the average transmission time by the above-mentioned equation (1) for the TCP/IP throughput. The measured average Ping round trip time [T.sub.RTa] and the measured loss rate [p.sub.a] are used as the parameters [T.sub.RT] and p in the equation (1). Other parameters for the TCP/IP used this calculation are shown in Table 2.
Table 2. TCP/IP Parameters used for Throughput Calculation

Parameter                     Client    Server

TCP algorithm                New Reno  New Reno
Max. segment size            1.460 kB  1.460 kB
Max window: [W.sub.m]           10        10
Average time out: [T.sub.O]      3           3


Figure 9 compares the theoretical calculation and measurements of the average access time [T.sub.Aa] of "getValues" for 1000 objects. The average loss rates for all locations were assumed to be p = 0.002 for the calculation. This is because the throughput [S.sub.a] is hardly affected by the values of p less than 0.002, although each measured average loss rate is not exactly the same.

[FIGURE 9 OMITTED]

The constant overheads in the transmission time as compared with the calculation were observed for all locations. Each measured average access time [T.sub.RTa] was approximately 1 s longer than the calculated value. The constant overheads time includes the Web Server process time [T.sub.SP] = 0.3 s. The value of [T.sub.SP] was measured using the actual testing device for this field test. However, there is still an unknown component of overheads of about 0.7 s.

Thus, the transmission time of BACnet/WS object access over the Internet can be evaluated by theoretical calculation, once the average IP packet round trip time and loss rate have been obtained. These parameters are very easily measured by "Ping" probing that is widely used in the Internet community.

DISCUSSION

Components of BACnet/WS Access Time

So far, this paper has dealt with only the transmission time for the BACnet/WS object access. In case that the transmission is carried out over the short network, the transmission time might not be a significant portion. However, the transmission time will take the largest portion of the total service time in case that the server has a cache memory for BACnet/WS objects. In addition, the transmission time will become more important if the transmission is carried out over the Internet.

Figure 10 shows time components of the total service time of the BACnet/WS "getValues" for 1000 objects for different network distances. The component of the transmission time was taken from the field test result [T.sub.Aa]. The component of the BACnet/WS server process time for the "getValues" message data [T.sub.SP] for 1000 objects was taken from the actual experiment of a typical server device. The total VRF fieldbus communication time to collect 1000 I/O points was assumed to be 5 s, which is independent of client locations.

[FIGURE 10 OMITTED]

The bit rate, in other words, bandwidth of the Internet, will rapidly increase in the near future. But the propagation delay of each packet over a long distance, such as between the continents, can not be reduced because it is a physical phenomenon. Since the TCP/IP is basically a type of confirmed protocol, the sender can transmit only limited number of packets before confirming the receiver's acknowledgement. It is known that the large bandwidth-delay product is one of the main problems of the TCP/IP transmission over the Internet. The transmission time for the total number of packets for a message will not necessarily become shorter as a function of the bandwidth. Therefore, even in the near future, the time of the BACnet/WS access for a large number of objects over the Internet will not become significantly shorter than the present level.

Influence of the Number of Objects in One Access

Prediction of the transmission time in the system-planning phase is valuable for the design of a BACnet/WS system before actual operation. This research has found that the transmission time has a strong linear correlation with the average Ping round trip time. However, the average Ping round trip time cannot be changed by a designer of the remote management system for air-conditioners. Since the transmission time is obtained by dividing the message length by the TCP/IP throughput, the transmission time is also expected to be proportional to the number of objects. Therefore, consideration on the number of objects read in one access is an important design parameter for remote management systems for VRF air-conditioners.

Figure 11 shows the relationship between the number of objects [N.sub.O] in one access and the average access time [T.sub.Aa] for the "getValues" service in the case of the client location of London. The client location was chosen because of the longest transmission time among the field test locations. The values of [T.sub.Aa] from both the theoretical calculation and field test were plotted against [N.sub.O]. The parameters of calculation were chosen as the measured average round trip time [T.sub.RTa] = 0.278 and the measured packet loss rate [p.sub.a] = 0.002 for the case of the client's location of London. The calculated average transmission times matched with the measurements in the field test in the cases of the number of objects [N.sub.O] of one, 500 and 1000 as shown in Figure 11.

[FIGURE 11 OMITTED]

The results of this calculation can be used for prior consideration on how many objects should be read at one BACnet/WS "getValues" service. Generally speaking, an operator might experience delay in the response in an interactive information system if the response is more than approximately three seconds. A system designer of a BACnet/WS remote management system over the Global Internet can estimate the transmission time, and make a decision on how many objects should be accessed in one "getValues" request. Therefore, this paper's proposal of using the TCP/IP throughput calculation for estimating the BACnet/WS transmission time will be useful for designing a BACnet/WS remote management system over the Global Internet.

CONCLUSION

This paper has provided the theoretical and experimental studies on the communication performance of the BACnet/WS object access over the Global Internet. The following useful conclusions were obtained.

1. The transmission time of the BACnet/WS access for a large number of objects accounts for most of the total service time for the cases of the Global Internet. For an extreme example, the average single access of 1000 objects takes 10 to 20 seconds.

2. The average service time of the BACnet/WS object access can be estimated by a TCP/IP theoretical throughput equation. The difference between the calculation and experiment was constant overhead of approximately 1 second.

3. The average transmission time of the BACnet/WS object access is approximately proportional to the average round trip time of "Ping" probing and also to the number of objects in each BACnet/WS object access.

So far, enormous efforts have been given to the development of the BACnet/WS standard and to study of cooperation with enterprise-level management systems. However, very little efforts have been given to the aspect of data transmission performance of BACnet/WS over the Global Internet connections. Even though the BACnet/WS standard has been supposed to apply to non-realtime control applications, attention should be given to data transmission performance in the cases of extremely distant and unstable network conditions that are typical in the Internet environments. A systems designer should consider how much information should be accessed at a time considering the characteristics of TCP/IP protocol and recent Internet data transmission.

In this paper, we have proposed a prediction method for the communication performance of the BACnet/WS systems over the Global Internet. Our proposed method is useful for designing a BACnet/WS remote building management system over the Global Internet.

ACKNOWLEDGMENT

The authors would like to thank Dr.Yoshiyuki Honda for discussion on the application model of the BACnet/WS standard, and Mr. Tomohisa Yamada for his assistance in developing the software.

REFERENCES

ASHRAE 2004. ANSI/ASHRAE Standard 135-2004, A Data Communication Protocol for Building Automation and Control Networks. Atlanta: American Society of Heating, Refrigeration and Air-Conditioning Engineers, Inc.

ASHRAE 2006. ANSI/ASHRAE Addendum c to ANSI/ASHRAE Standard 135-2004, ANNEX N--BACnet/WS Web Services Interface. Atlanta: American Society of Heating, Refrigeration and Air-Conditioning Engineers, Inc.

Bushby, S. 1990a. Testing conformance to energy management and control system communication protocols--Part 1: Test architecture. ASHRAE Transactions, 96(2):1127-1133.

Bushby, S. 1990b. Testing conformance to energy management and control system communication protocols--Part 2: Test suite generation. ASHRAE Transactions, 96(2):1134-1141.

Bushby, S. 1998. Communication gateways. ASHRAE Journal, 40(4):50-53.

Goetzler, W. 2007. Variable refrigerant flow systems. ASHRAE Journal, 49(4):24-31.

Honda, Y., M. Inoue, Y. Ito, and T. Sato. 1993. Integrated network architecture for heating, refrigeration and air conditioning, ASHRAE Transactions, 99 (2):230-236.

Hong, S. and W. Song. 2003. Study on the performance analysis of building automation network. Proceedings of IEEE Symposium on Industrial Electronics, ISIE03, (1):184-188.

Hong, S. and W. Song. 2004a. Implementation of a bandwidth allocation scheme. Proceedings of IEEE Conference on Industrial Technology, ICIT04, (1):793-800.

Hong, S., W. Song, Y. Kwon, and T. Park. 2004b. A bandwidth allocation scheme on MS/TP protocol. Proceedings of IEEE Conference on Industrial Informatics, INDIN05, 1(1):523-528.

Huang, H., J. Yen, S. Chen, and F. Ou. 2004. Development of an intelligent energy management network for building automation, IEEE Transactions on Automation Science and Engineering, 1(1):14-25.

Ninagawa, C., M. Mizoguchi, and Y. Miyazaki. 2005. Traffic simulation of computer communication of BACnet/IP building air-conditioning control system. Journal of Institute of Electrical Installation Engineers in Japan, 25(12):55-62.

Ninagawa, C., T. Sato, and Y. Kawakita. 2008. Communication performance simulation for object access of BACnet web service building facility monitoring systems. Proceedings of IEEE International Conference on Emerging Technologies and Factory Automation, 1(1):701-704.

Padhye, J., V. Firoiu, and D. Towsley. 2000. Modeling TCP Reno performance: a simple model and its empirical validation. IEEE/ACM Transactions on Networking, 8(2):133-145.

Song, W., S. Hong, and S. Bushby. 2003. A simulation analysis of BACnet local area networks, National Institute of Standards and Technology, NISTIR7038.

Stevens, R. 1994. TCP/IP Illustrated, Volume 1, The Protocols. Boston: Addison-Wesley.

Tom, S. 2004. Web Services & BACnet. ASHRAE Journal, 46(10):S14-S17.

Tomboli, C. and C. Manikopoulas. 1995. Determination of the optimum packet length and buffersizes for the industrial building automation and control networks, Proceedings of IEEE International Symposium on Industrial Electronics, 2(1):831-836.

Yang, H., J. Burnett, K. Lau, and L. Lu. 2001. Comparing central and split air-conditioning systems. ASHRAE Journal, 43(5):36-38.

Yokohama, K., S. Hirata, T. Inaba, S. Hiramatsu, K. Takahashi, and H. Otake. 2008. Development of the Super Link II Communication System for Building Air Conditioners. Mitsubishi Heavy Industries Technical Review, 45(2):6-10.

Chuzo Ninagawa, PhD

Chuzo Ninagawa is chief engineer in the Air-Conditioner Designing Department and Tomotaka Sato is manager in the Electronic Equipment Designing Section, Air-Conditioning & Refrigeration Systems Headquarters, Mitsubishi Heavy Industries, Ltd., Kiyosu, Aichi, Japan. Yahiko Kawakita is senior engineer in the Systems Development Department, MHI Aerospace Systems, Corp., Nagoya, Aichi, Japan.
COPYRIGHT 2009 American Society of Heating, Refrigerating, and Air-Conditioning Engineers, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2009 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Ninagawa, Chuzo; Sato, Tomotaka; Kawakita, Yahiko
Publication:ASHRAE Transactions
Article Type:Report
Geographic Code:9JAPA
Date:Jul 1, 2009
Words:5299
Previous Article:Common data definitions for HVAC&R industry applications.
Next Article:Comparative analysis of optimization approaches to design building envelope for residential buildings.
Topics:

Terms of use | Privacy policy | Copyright © 2021 Farlex, Inc. | Feedback | For webmasters |