Printer Friendly

BACnet object modeling by UML on high-level functionality of VRF air-conditioning systems.


The BACnet standard established by ASHRAE is now an ISO standard (ASHRAE 2004). It is becoming more and more popular, not only in North America but also in Asian and European countries, where variable refrigeration flow (VRF) air-conditioning systems are widely used for commercial buildings (Goetzler 2007; Yang et al. 2001), and cases of BACnet implementation in VRF systems have been increasing.

The BACnet standard defines a set of BACnet object types that are generic data structures. It is claimed that they can represent all types of target objects from a network point of view (ASHRAE 2004). However, the VRF system is a type of distributed packaged air-conditioning system that is quite different from conventional chiller-and-duct air-conditioning systems. It is necessary to consider a better application of the BACnet standard to VRF systems.

So far, there have been some research papers on BACnet regarding conformance testing (Bushby 1990a, 1990b), communication traffic (Tomboli et al. 1995; Hong et al. 2003), implementation modeling (Huang et al. 2004), and so on. One of the most important research themes for BACnet is the implementation of high-level functionality of air-conditioning systems. Because the set of BACnet standard object types are just groups of generic and autonomous definitions of data structure, they do not provide inter-relation or hierarchy of the composition of objects. When implementing application-specific high-level functionality using BACnet standard object types instead of just I/O components, a clearly defined model for representing the inter-relationship between the BACnet objects is necessary.

Some articles on modeling high-level functionality-for example, modeling of the BACnet objects in the access control system-were published in ASHRAE Journal (Ritter et al. 2006). It discusses problems of representing application-specific and high-level functions using generic BACnet standard object types. The article uses the author's own method of modeling, which is not a formal definition of modeling. Few academic research papers on how to formally model abstract high-level functionality using the BACnet standard object types have been published.

One of the important issues about implementing BACnet objects in a VRF system is how to model the relationship or hierarchy of the group of BACnet objects. In addition, the model should be represented by an international standard modeling language. It is almost impossible for software engineers from different vendors to understand interrelated behavior of the group of objects if a huge number of objects are just placed in a manner of plain aggregation.

Today's most common modeling language among software engineers is the Unified Modeling Language (UML) (Booch et al. 1999). UML is an ISO standard and also a de facto standard modeling language in the field of architecture modeling of software-intensive systems (Lange et al. 2006). Some research papers reported that UML is suitable to model a network view of the communication protocol implementation (Jaragh et al. 2000; Lee et al. 2004; Lee et al. 2005).

Multivendor situations in the building management system (BMS) networks are the right targets for which the BACnet standard was intended from the beginning. Therefore, providing a network view model of the relationships among the high-level function objects via the de facto standard formal modeling language is quite useful for mutual understanding among vendors from multiple manufacturers.

The first feature of this paper is our method of modeling via the UML language for BACnet object implementation on high-level functionality for VRF air-conditioning systems. The second feature is the concept of a virtual wattmeter using the BACnet Accumulator standard object type indicating power consumption allocation to each indoor unit in the VRF system. Through this research, the efficiency of the proposed implementation model in terms of BACnet communication traffic was confirmed by computer simulations. In addition, the effectiveness of this fair and accurate allocation method for the total power consumption was evaluated by experiments. Consequently, this paper presents an efficient and effective BACnet object implementation model for the VRF air-conditioning systems.


VRF Air-Conditioning Systems

Figure 1 shows a typical system diagram of a VRF air-conditioning system. A typical VRF air-conditioning system consists of several tens of outdoor units and hundreds of indoor units. An outdoor unit works as a condensing unit, and an indoor unit works as an evaporating unit in the case of the cooling operation mode. The outdoor units are usually placed on the roof of the building, and the indoor units are often embedded in the ceilings of the building.


All indoor and outdoor unit controllers are connected with a set of communication network links by bus connection for all the refrigerant circuit modules. This VRF control network carries not only low-level control messages between indoor and outdoor units, but also high-level management messages between the indoor units and a gateway to the BMS network. That is to say, the communication of low-level refrigeration control and high-level management share the same VRF control network.

Figure 2 shows a conceptual diagram of one of the refrigerant circuit modules. Each module typically consists of an outdoor unit and several indoor units. In general, an outdoor unit includes a controller, an inverter-driven refrigerant compressor, a heat exchanger, and other refrigerant circuit components. Each indoor unit includes a controller, a heat exchanger, a blower fan, and an electronic expansion valve (EEV). The indoor unit controller modulates the expansion valve in order to regulate the refrigerant flow into its heat exchanger according to the heat load variation of the indoor unit.


To make the compressor of the outdoor unit send enough refrigerant to meet all the indoor units' demand, each indoor unit controller periodically sends a Request_Ref_Flow message to the outdoor unit controller via the VRF control network. The outdoor unit controller periodically sums up these requests and decides its output flow rate of refrigerant by varying the rotation speed of the inverter-driven compressor. The outdoor unit then sends the available flow rate, called the Answer_Ref_Flow, to each indoor unit controller. Each indoor unit regulates the opening of its electronic expansion valve according to the Answer_Ref_Flow allocated from the outdoor unit controller. These exchanges of low-level messages for control of the air-conditioning system are performed in the autonomous manner from the BMS point of view.

BACnet Controller Using VRF Control Network

Each VRF manufacturer has its own proprietary control network system dedicated to controlling the VRF air-conditioning system (Honda et al. 1993; Ninagawa et al. 2006). Although the communication protocol of these control networks is different from manufacturer to manufacturer, basic methods and specifications are more or less similar. Therefore, there should be a suitable implementation model for the BACnet advanced application controllers (B-AAC) or application specific controllers (B-ASC) that takes advantage of the above-mentioned autonomous nature of the VRF control network. The following are the common characteristics of various manufacturers' VRF control networks.

Usually, the topology of the VRF control network is a type of bus connection, and the maximum length of the transmission line is more than 1000 m. The total number of the indoor and outdoor units connected to one system of the VRF control network is approximately 100. The packet length of each message on the VRF control network is up to several tens of bytes. The transmission bit rate is typically 9600 bps. The medium access control method is likely to be a type of carrier sense multiple access with collision detection (CSMA/CD). The CSMA/CD type does not require master-slave relation between controllers on the network, and this is one of the bases of the autonomous nature of the VRF air-conditioning system.

The VRF control network communication interface is embedded in the controller of each indoor and outdoor unit during mass-production in the factory because it is the most inexpensive way. Therefore, it is redundant if a communication interface for the BACnet datalink-layer protocol, such as the MS/TP (master slave token passing), is added on to each indoor and outdoor controller.

One of the important characteristics of the VRF control network is that the encoding rule of the communication messages is vendor dependent and usually encoded in binary form. It is impossible for a BMS host computer from a different manufacturer to decode and interpret the communication messages. Therefore, at least, a kind of gateway between a proprietary VRF control network and a BACnet BMS network is inevitable as long as the VRF system is involved in BACnet projects.

The embedded controllers of indoor or outdoor units connected to the VRF control network form a kind of distributed control system. A VRF control network does not need any single master controller because of the autonomous nature of the VRF system and the CSMA/CD protocol. In a sense, an outdoor unit is like a parent because it distributes the refrigeration flow to its child-like indoor units. However, there are plural outdoor units, and they are in the peer to peer relationship because each refrigeration circuit module is independent.

Using the above-mentioned control network framework, it is possible to concentrate the BACnet objects on the single gateway device as a B-ASC. In this case, the collection of the BACnet objects represent the high-level functionality of the VRF system, instead of representing merely I/O components, using the above-mentioned management messages on the VRF control network.

In general, a gateway is defined as a communication device that performs protocol translation (Bushby 1998). We call this device a BACnet VRF controller because the device is not just a communication protocol translator, it has the BACnet high-level functionality that is described in the following sections.


Concept of an Air-Conditioner Cell

As mentioned above, VRF air-conditioning systems are autonomous distributed systems. Therefore, it is not necessary for the BMS to directly control and monitor each I/O component, such as sensors, valves, fan motors, etc. Instead of these elemental components, via the BACnet VRF controller, the BMS can manage high-level functions, such as operation mode setting or error code indication for each logical group of indoor units, that is a management target, separate from the entire air-conditioning system.

This concept of management target is similar to a concept of a zone in the cases of the BMS for chiller-and-duct air-conditioning systems. The term "zone" means the space of rooms or floors defined by dividing areas of the building, not only the machinery of the air-conditioning system itself. But, it seems that there is no standard formal model for the concept of a zone. Since each vendor defines its own data structure for the zone in an ad-hoc way, the interoperability of the definition of zones is not established. In the case of this zone concept, when controlling actuator components or monitoring sensing components, a BACnet controller needs to access each I/O component installed. Therefore, we denote this method as the I/O device method.

In 1995, we introduced a concept of air-conditioner cell, which represents not only a divided zone for air-conditioning but also an abstract portion of the entire air-conditioning system from a BMS point of view (Honda et al. 1995). The concept of the air-conditioner cell provides the BMS with a BACnet network view of a management target divided from the entire air-conditioning system, including the outdoor units. This concept of an air-conditioning cell is not merely an existing concept of a divided area of the building, but a high-level managing target for a virtual partitioning of the VRF system, including abstract member functions, such as the operation-mode setting or error-code indication.

Figures 3 and 4 compare the difference in the above-mentioned concepts and another model based on the air-conditioner cell concept. Figure 3 represents a conventional I/O device model consisting of a plain array of BACnet standard objects corresponding to I/O components. On the other hand, Figure 4 represents an abstract model consisting of a structured set of BACnet standard objects of the high-level functions of the air-conditioner cell. In the next section, we will describe the detailed logical structure of the air-conditioner cell model via UML.



UML Modeling of an Air-Conditioner Cell

Class is a basic keyword in many object-oriented modeling or programming languages. In these languages, a class is supposed to be a kind of template for objects by defining common attributes and operations. Each instance of an object is considered to be created from the class, inheriting the attributes and operations of that class. An attribute is a named property of a class, and an operation is the implementation of a service that can affect the attributes of the class.

A UML class diagram represents the relationship among the classes in the target system. A class is rendered as a rectangle in UML, with the class name, attributes, and operations in the upper, middle, and lower compartments. The relationships among classes are rendered by several types of lines, with some notations defined by UML.

Figure 5 shows a UML class diagram that represents a static structure of the BACnet objects for the high-level functions for the air-conditioner cell of a VRF air-conditioning system. In Figure 5, a class VRFController is a specific case of the BACnetDevice type. It is a network view for the whole device. The VRF controller is a B-ASC in which all BACnet objects are implemented. Following UML rules, the relationship between two classes is rendered by a solid line with a triangle arrowhead pointing at the general class. Furthermore, the UML class diagram shows the class of VRFController is composed of a number of classes of AirConditionerCell and only one class of PhysicalWattMeter. The class of AirConditionerCell corresponds to the above-mentioned management target air-conditioner cell. The AirConditionerCell defined here is composed of several classes of member functions, such as classes of OperationStart, OperationMode, and so on, and also by a class of OperationAmount. This type of relationship between the classes is called a composition-in other words, a whole-part relationship in UML. The relationship is represented by a line with a black diamond pointing at the whole end. The number at each end of a composition relationship line denotes the number of instances of the objects created from the class.


UML Classes of BACnet VRF Controller

In the air-conditioner cell implementation model, the class AirConditionerCell is defined so that it has a number of member functions. These functions correspond to high-level management items for the target portion of the VRF system from the BMS point of view.

The class of OperationStart represents a target of the operation command from the BMS to an object of the class of AirConditionerCell. This function is similar to the operation of an ON/OFF switch on a wall-mounted remote controller of a specific indoor unit of the VRF system. Since the object of this class takes a binary output value (start/stop), this class is inherited from the BACnetBinaryOutput type. The class of OperationMode is for setting the air-conditioning mode to cooling, heating, dry, fan-only, or auto operation. Since the BMS writes one of above-mentioned modes to an object of this class, the class is inherited from the BACnetMultiStateOutput type. In addition, other member function classes of SetpointTemp and RoomTemp are self explaining and derived from the BACnetAnalogValue and BACnetAnalogInput types, respectively. In the case that an instance of the object of the AirConditionerCell corresponds to a group consisting of more than one indoor unit, each object of SetpointTemp and RoomTemp is defined as that of the representing indoor unit in the group.

In Figure 5, we defined two more interesting member function classes of ErrorCode and VirtualWattMeter, which characterize our BACnet object modeling because these classes are for typical abstract high-level functions. They do not correspond to any actual physical things.

The class of ErrorCode, which is an instance of the class of BACnetMultiStateInput type, indicates one of the categories of the failures of not only the indoor unit but also the pairing outdoor unit. It does not necessarily mean the failure has occurred in any part in the indoor unit. In the case of conventional implementation of BACnet objects corresponding to the I/O components, each object may contain the mechanism of the BACnet intrinsic reporting of abnormality. In the conventional implementation, the BMS distinguishes the component in failure by the instance number of the object for the I/O component. In the case of AirConditionerCell, however, the BMS can distinguish failure mode by the PresentValue in the ErrorCode object. There are some failure types that cannot specify the component, such as control network address duplication, over connection of indoor units, and so on. In general, networked control systems of VRFs are intelligent enough to diagnose and categorize the cause of malfunction in the proprietary error code of the air-conditioning system.

Another high-level member function is the class of VirtualWattMeter that also does not correspond to any physical component. This class is for the VirtualWattMeter objects that indicate accumulated power consumption not only by the indoor unit but also the apportion of the outdoor unit. Each VirtualWattMeter object is allocated to a specific AirConditionerCell object. For the Class of VirtualWattMe-ter, we chose the BACnetAccumulator type from the BACnet standard object type. The concrete description of this class will appear in a later section.

High-Level Relationship among Function Classes

As shown in figure 5, following UML rules, broken lines with an arrowhead are found representing the relationship of dependency between the classes. There is only one class of PhysicalWattMeter that corresponds to an actual watt-hour-meter. It measures the total accumulated power consumption of the entire VRF air-conditioning system. Each class of AirConditionerCell has one class of OperationAmount that represents the integral of refrigeration flow through the electronic expansion valve embedded in each indoor unit.

The classes of PhysicalWattMeter, OperationAmount, and AllocationCalculator are not network-visible from the BACnet BMS point of view. Thus, the attributes in these invisible classes have the prefix of "--" according to the UML rule. The class of AllocationCalculator is dependent on the classes of PhysicalWattMeter and OperationAmount. The attribute of cellWattIncrement of the class AllocationCalculator represents the calculated amount of power consumption divided from the total power consumption. Each power consumption allocation is calculated using cellRefFlowValue by the algorithm that will be described in the following section. However, from the BACnet BMS point of view, the internal calculation is hidden away. Only the result value is placed in the Present-Value, which is network visible, of the abstract objects of the VirtualWattMeter.


Power Consumption of an Air-Conditioner Cell

One of the advantages of the modeling using the air-conditioner cell is that this concept makes it possible to allocate the power consumption to each managing target, that is the air-conditioner cell, including a portion of the outdoor unit's consumption.

The VRF is a type of decentralized air-conditioning system that makes it possible to turn ON/OFF each indoor unit and to adjust the inverter-driven compressor power of the outdoor units according to the sum of the demand from operating indoor units. Since VRF air-conditioning systems are often installed in multitenant commercial buildings, it is important to measure the power consumption of each air-conditioner cell in order to provide each tenant with a fair power consumption bill. However, it is not easy to measure the power consumption because the majority of the power is consumed by the compressor in the outdoor unit that is shared by a number of indoor units. Installing a wattmeter on each indoor unit for allocation of the power consumption is not applicable because each indoor unit merely consumes power for fans and valves only. The wattmeter cannot evaluate the apportionment of the compressor power consumption to the specific indoor unit.

The total power consumption of an entire VRF air-conditioning system is usually measured by watt-hour meters at the electric power supply point of the building. The BMS can evaluate the total power consumption by accessing a BACnet controller for the power supply facility with the watt-hour meters. In addition, the BMS can evaluate the accumulated operation hours of each indoor unit. Therefore, it is supposed to be one of the methods that the BMS allocates the power consumption to each indoor unit using each indoor unit's accumulated operating hour as a proportional coefficient.

However, this operation-time-proportional method cannot evaluate each tenant's effort to save energy, for example, by adjusting the setpoint for the room thermostat of the indoor unit to a moderate level. Instead, we supposed that it is fairer to allocate the power consumption proportional to the accumulated amount of refrigerant flow that flows into the indoor units that compose the air-conditioner cell. As described in the second section, each indoor unit periodically calculates the difference between the setpoint temperature and the sampled room temperature. Then, it sends messages of the Request_Ref_Flow to the outdoor unit and regulates its own EEV according to the response of Answer_Ref_Flow.

The above-mentioned modeling of the air-conditioner cell makes it possible to evaluate the accumulated amount of the refrigerant flow of a specific portion of the VRF system, because each indoor unit controller can send the messages of the refrigerant flow rate by the opening position of the EEV. Using the messages, the BACnet VRF controller is able to calculate the power consumption allocation to the abstract management target, the air-conditioner cell.

Power Consumption Allocation Algorithm

Figure 6 shows the concept of the power consumption allocation of the virtual wattmeter in each air-conditioner cell. The calculation is to be carried out periodically-for example, every hour or at midnight-by the BACnet VRF controller. The principle of the allocation calculation is based on the concept of the variable Operation_Amount that represents the relative amount of the accumulated refrigeration flow consumed by the specific indoor unit.


Here, the allocation calculation timings are denoted as t = [t.sub.1],[t.sub.2],[t.sub.3]..., [t.sub.k-1],[t.sub.k + 1],...[t.sub.K],...The total refrigeration flow from the outdoor units throughout the entire VRF system is denoted [R.sub.T] (t) that is equal to the summation of the refrigeration flow [R.sub.Ci](t) of each air-conditioner cell, and [R.sub.Ci(t)] is the summation of the refrigeration flow [R.sub.IUij] (t) into each j-th indoor unit of the i-th air-conditioner cell. Thus, the total refrigerant flow rate can be expressed in the following mathematical equation:

[R.sub.T](t) = [N.summation over (i = 1)][R.sub.Ci](t) = [N.summation over (i = 1)][[M.sub.Ci].summation over (j = 1)][R.sub.Iuij](t) (1)

where i = 1, 2, 3,..., N is the index number of the air-conditioner cells, and j = 1, 2, 3, ..., [M.sub.Ci] is the index number of the indoor units that consists of the i-th air-conditioner cell. In Figure 6, it is assumed that each air-conditioner cell consists of only one indoor unit (i.e., [M.sub.Ci] = 1 for all air-conditioner cells) for simplicity.

The increment of Operation_Amount of the i-th cell during the A:-th allocation period is defined as follows:


Here, [K.sub.IUij] is given by the look-up table that defines the specific value of this coefficient, depending on the air-conditioner type of the indoor unit. We define the increment of the power consumption allocated to the i-th air-conditioner cell during the k-th allocation period as follows:

[DELTA][P.sub.Ci]([t.sub.k]) = [C.sub.Ci]*[DELTA][P.sub.T]([t.sub.k]) = {[DELTA][A.sub.Ci]([t.sub.k]) [N.summation over (i = 1)] [DELTA] [A.sub.Ci]([t.sub.k])}*[DELTA][P.sub.T] ([t.sub.k]) (3)

Here, [C.sub.Ci] is the coefficient for distribution of the total power increment [DELTA][P.sub.T] ([t.sub.k]) that has been consumed by the entire VRF air-conditioning system during the k:-th allocation period by counting the input pulses from the physical wattmeter. In our method, the coefficient [C.sub.Ci] is given in proportion to the Operation_Amount [DELTA][A.sub.Ci] ([t.sub.k]) as shown in Equation 3.

Thus, the Accumulated_Power_Consumption [P.sub.Ci]([t.sub.k]) at t = [t.sub.k] can be calculated as follows:

[P.sub.Ci]([t.sub.k]) = [P.sub.Ci]([t.sub.k - 1]) + [DELTA][P.sub.Ci]([t.sub.k]) (4)

Therefore, the accumulated power consumption allocated to the i-th air-conditioner cell at an arbitrary time t between [t.sub.k] and [t.sub.K + 1] is given by the following equation:

[P.sub.Ci](t) = [K.summation over (k = 1)] [DELTA][P.sub.Ci]([t.sub.k])([t.sub.K][less than or equal to] t < [t.sub.K + 1]) (5)

Since the class of the VirtualWattMeter is derived from the class of the BACnetAccumulator, the value of the Accumulated_Power_Consumption [P.sub.Ci](t) is saved in the Present_Value property in the i-th VWMi object of the VirtualWattMeter class, as shown in Figure 6. Therefore, the BMS can easily obtain the current accumulated power consumption allocated to a specific air-conditioner cell by just reading the Present_Value of the specific VWMi object using a BACnet standard ReadProperty or ReadPropertyMutiple service.


Effectiveness of Air-Conditioner Cell Model

Since every VRF system has its own control network framework, each BACnet object does not actually have to be implemented on each controller of the indoor or outdoor unit. Instead, all BACnet objects can be implemented to only one BACnet VRF controller. Since the total number of BACnet objects would usually be in the hundreds or thousands, there should be some organizing or ruling model for the huge number of BACnet objects. Our air-conditioner cell model is one of the solutions for this problem. This model makes structured and concentrated implementation of any number of the BACnet objects on one BACnet VRF controller possible.

This concentrated implementation creates an advantage in the communication access time of the BACnet objects from the BMS because many objects can be accessed in one communication message sent to only one destination device. That significantly reduces the total access time of the status scanning of the VRF system.

We compared the computer simulations of access time for the system status scanning between the above-mentioned two BACnet object implementation models shown in Figures 3 and 4. This computer simulation experiment assumed that the BMS reads the PresentValue and the StatusFlags of 1000 BACnet objects for the entire VRF system using the BACnet ReadPropertyMultiple services via a typical BACnet/IP network.

In the case of our air-conditioner cell method, we assume that all 1000 BACnet objects are implemented to only one B-ASC-in this case, the BACnet VRF controller. On the contrary, in the case of the conventional I/O device method, we assume that only one BACnet object is implemented to each of 1000 BACnet simple controllers for simple comparison.

Table 1 shows the total simulation access times [T.sub.TA] for the above-mentioned 1000 objects in both cases of the I/O device method and the air-conditioner cell method. The [T.sub.TA] for the air-conditioner cell method was less than 1 s and approximately one-tenth that of the I/O device method. Of course, the value varies case by case, but the effect of concentrating the destination of the communication packets on reducing the network communication traffic is significant when reading more than hundreds of objects in the ordinary 10 or 100 Mbps Ethernet network environment.
Table 1. Example of Computer Simulation of Access Time for Reading 1000

Method                         Air-Conditioner  I/O Device
                                 Cell Method      Method

No. of BAC net devices for a          1           1000
VRF system

No. of objects for one access      46 (1)            1

No. of ReadPropertyMultiple      23 = 1000/46       1000

Average of one access time:      11-41 ms (2)   2.8-11 ms (2)

Total access time: [T.sub.TA]  0.25-0.95 s (2)  2.8-11 s (2)

(1.) Decided as the maximum number for one BACnet nonsegmented APDU
(2.) Varies depending on the background traffic conditions

Comparison between VirtualWattMeter Method and Conventional Method

Figure 7 shows an example of the comparison of power consumption allocation profiles between the conventional operation time proportional method and the refrigeration flow proportional method of the proposed virtual wattmeter concept. An example comparison was made using an actual field operation test during one month for four objects of AirConditionerCell class, namely Cell_1, Cell_2, Cell_3, and Cell_4, on the BACnet VRF controller for a small office building. In the example field test, the operation time for the Cell_1 was 260 hours, and that for the Cell_2, Cell_3, and Cell_4 was 233 hours. In the case of the operation time proportional method, the allocated power consumption for the Cell_1 is greater than that for the rest of the air-conditioner cells, and each allocated power consumption for the rest of the air-conditioner cells is the same because the operation time is the same. On the contrary, in the case of the refrigeration flow proportional method, each allocated power consumption, which is read from the virtual wattmeter object VWMci for Cell_2, Cell_3, and Cell_4, is different because of the difference in the accumulated amount of the refrigeration flow into each air-conditioner cell. This is one example of the monthly power consumption allocation using our virtual wattmeter method. In this stage of our research, we cannot provide a general quantitative comparison between the two methods. However, this example clearly identifies a potentially viable method for measuring the difference in the power consumption allocation between air-conditioner cells with different refrigerant usage. In other words, the power consumption of specific parts of the VRF system are allocated depending on the manner of operating the air-conditioner. The lower the room temperature setpoint or the higher the air-conditioner heat load for the specific air-conditioner cell, the greater the allocated power consumption of the cell becomes by the proposed method of measurement.


In general, tenants of commercial buildings are sensitive to air-conditioning power consumption bills. If tenants put forth effort to decrease the air-conditioner operation time or to adjust the room temperature setpoint to reduce the bill, the total power consumption of the VRF system will be decreased. Therefore, this method will contribute to the energy savings of air-conditioning for office buildings.


This paper has provided a BACnet implementation model for abstract high-level functionality of VRF air-conditioning systems for commercial buildings.

Presented here is a new model of BACnet object implementation for high-level functionality for using the UML modeling language. Using the concept of an air-conditioner cell makes the network view from the BMS more robust for variation of physical components from different vendors. It also makes it more robust for future modification of the air-conditioners themselves.

The feature of function-member in the model is the virtual wattmeter, which indicates accumulated amount of power consumption using the BACnet Accumulator object type. Our concept of the virtual wattmeter contributes to fair allocation of the total power consumption of each air-conditioner cell using the refrigerant flow amount distributed to each air-conditioner cell. The UML model gives a strong foundation for implementing the BACnet objects for the high-level BMS management functionality into the B-ASC for the VRF air-conditioning systems.


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

Booch, G., J. Rumbaugh, and I. Jacobson. 1999. The Unified Modeling Language User Guide. Upper Saddle River, NJ: Addison-Wesley.

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

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

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

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, refrigerating and air-conditioner. ASHRAE Transactions 99(2):230-36.

Honda, Y., M. Minami, K. Tamakoshi, and C. Ninagawa. 1995. Building Air-Conditioning System Interface/Command List JRA5004-1995. Tokyo: Japan Refrigeration and Air-Conditioner Industry Association.

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

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.

Jaragh, M., and K. Saleh. 2000. Modeling communications protocols using the unified modeling language. Proceedings of IEEE Region 10 International Conference on Electrical and Electronical Technology (2):271-75.

Lange, C., M. Chaudron, and J. Muskens. 2006. In practice: UML software architecture and design description. IEEE Software 23(2):40-6.

Lee, J., and P. Hsu. 2004. Design and implementation of the SNMP agents for remote monitoring and control via UML and Petri Nets. IEEE Transactions on Control Systems Technology 12(2):293-302.

Lee, K., and Y. Song. 2005. Object-oriented application framework for IEEE 1451.1 standard. IEEE Transactions on Instrumentation and Measurement 54(4):1527-33.

Ninagawa, C., K. Yokohama, F. Aoi, H. Otake, and Y. Miyazaki. 2006. Transmission characteristics of UART-CSMA/CD control network with one-chip microcontroller and RS-485 driver IC. Proceedings of Progress In Electromagnetics Research Symposium, PIERS-Tokyo, Tokyo, Japan, pp. 271-75.

Ritter, D., B. Isler, H. Mundt, and S. Treado. 2006. Access control in BACnet. ASHRAE Journal 48(11):B26-B32.

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

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

Chuzo Ninagawa, PhD

Tomotaka Sato

Chuzo Ninagawa is chief engineer in the Air-Conditioner Designing Department and Tomotaka Sato is manager in the Electronic Equipment Designing Section of the Air-Conditioning & Refrigeration Systems Headquarters, Mitsubishi Heavy Industries, Ltd., Kiyosu, 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
Title Annotation:variable refrigeration flow; Unified Modeling Language; Building Automation and Control Networks
Author:Ninagawa, Chuzo; Sato, Tomotaka
Publication:ASHRAE Transactions
Article Type:Report
Geographic Code:1USA
Date:Jan 1, 2009
Previous Article:Advancing automated demand-response technology.
Next Article:Calibration of a building energy model using measured data.

Related Articles
A Performance Analysis of BACnet[R] local area networks.
Advancing automated demand-response technology.

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