{'fraction_non_alphanumeric': 0.023980134799574317, 'fraction_numerical': 0.010074494501596311, 'mean_word_length': 4.910272536687631, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Research on Brick Schema Representation for Building Operation with Variable Refrigerant Flow Systems

Building metadata is regarded as the signpost in organizing massive building data. The application of building metadata simplifies the creation of digital representations and provides portable data analytics. Typical metadata standards such as Brick and Haystack are used to describe the data of the building system. Brick uses standard ontologies to create building metadata. However, neither Haystack nor Brick has provided definitions about the Variable Refrigerant Flow (VRF) system so far. For years, both Brick and Haystack working groups have been discussing how to describe VRF in their schema, mainly about the classification of VRF and the definitions of VRF units. There were no settled solutions for these problems. Meanwhile, the global VRF market is growing increasingly fast because of the energy efficiency and installation simplicity of the VRF system. It is needed to have the metadata to describe VRF units in buildings for data analysis and management. Addressing this challenge, this paper extended Brick Schema with the VRF module and verified the Brick VRF module. Then, the model and the service framework were developed and applied for a building in China. The framework can serve portable energy analysis for different areas. The VRF module of this paper provides a possible solution for the expression of the VRF system in the building semantic web. The works in this paper will support semantic web in automation strategies for building management and scalable building operation.


Introduction
Buildings have interdependent systems and components for various purposes, such as building operation, indoor environment quality, security, and Heating, Ventilation, and Air Conditioning (HVAC). More than the one-third energy consumption of commercial buildings is from HVAC (U.S. Energy Information Administration 2020). Among them, more than 80% of commercial buildings in Europe and East Asia use Variable Refrigerant Flow (VRF) systems for HVAC (Joanna R. Turpin 2017). Compared with the traditional HVAC devices, the VRF system has advantages in satisfying part-load performance, flexible individual control, no duct delivery loss, and easy installation and maintenance (Zhang et al. 2019;Zhao, Zhang, and Zhong 2015). The simplification of the pipelines benefits from the ingenious design of the indoor and outdoor units.
Consequently, the indoor and outdoor units of the VRF system are very sophisticated, because nearly all the sensors, valves, and control units are integrated inside them.
Meanwhile, the VRF is undergoing an accelerated growth. The global VRF market is expected to reach USD 30.89 billion by 2025 (Verified Market Research 2018). The complicity and popularity of the VRF system make it crucial to the successful management of building energy.
To precisely and properly manage building energy, smart building, and digital twin have gained attention (Metallidou, Psannis, and Egyptiadou 2020;Teng et al. 2021). Smart building requires effective coordination and even integration of these independent systems, which has become the mainstream for collaborative operation and maintenance of assets and infrastructures. The smart building relies on correct and precise digital reflection of the real world using digital twin, making the access and analysis of data a great challenge.
Haystack was introduced to deal with this challenge. It provides building components definition and relationship deductions through tags. It brought the concept of Tag to building metadata, which is an effective method to represent, transfer, and explain data.
A tag is a name/value pair applied to an entity. For instance, the id tag representing an entity has a Ref value in (id: @whitehouse). Tags represent the facts about data items and can be associated with roll calls to provide information describing objects. Also, Haystack brought standard and extendable libraries of tags. It has model implantations, application specifications, and data serialization formats. The emergence of Haystack provides a way for building systems and intelligent devices to implement automatic interpretation and common vocabulary in various software and web-based applications.
Although Haystack intended to streamline working with data from the Internet of Things through standardization and externality tagging labels, there are problems during its application. Bergmann et al. (2020) summarized several issues of Haystack.
They pointed out that Haystack lacks verification, due to its vast definition of models, applications, and formats. The models in Haystack lack readability, they are neither articulated nor machine-interpretable. Another issue is that Haystack did not provide example applications or manuals for applying the schema.
Brick inherited the ideas from Haystack and described metadata with Entity, Class, Relationship, and Graph (Balaji et al. 2018). Brick intends to connect all sorts of building data through the building's lifecycle (Gabe Fierro, Prakash, et al. 2020).
Comparing with Haystack, Brick demonstrated better visualization and readability (Gabe Fierro, Koh, et al. 2020). Balaji et al. (2018) demonstrated Brick can map up to nearly all Building Management System (BMS) data points across six buildings.
Google has applied its digital building platform to more than 100 buildings with Brick as the resource description framework. Brick (Gabe Fierro et al. 2019) also provided an open test-bed for building operation data analysis.
Brick is trending, regarding building metadata representation. However, Brick has not supported modeling the VRF system since being promoted. Regarding cooling/heating system, brick schema only covered water-based system. The Brick group has been discussing the development of VRF for a while (Clement Bouvier Europe et al. 2020).
The first thing to consider is that there are no definitions of VRF or Hydrofluorocarbon in the schema. The dilemma is how to classify the VRF. The discussion about whether its classification is an Air Handling Unit, or a Chiller, or a Heat Pump has always been inconclusive. Because the roles of the VRF components change as the working mode changes.
Therefore, this study develops the VRF system in Brick Schema. The Brick VRF module is validated and applied to an office building. The paper is organized as follows, Section 2 explains the background of adopting Brick for managing VRF along with a comparison of the latest version of Brick Schema and Project Haystack. Section 3 presented the development of the VRF module in Brick. The application of VRF Brick modules in the BMS is demonstrated in Section 4. These are followed by a discussion in Section 5. Section 6 concludes the paper.

Brick for BMS
As mentioned above, Haystack has been criticized for a long time because of the lack of consistency of the system, which is the reason that Brick is trending. A comparison on model representation indicated that the performance of Brick (Version 1.1.0) was higher than Haystack (Version 3.9.7), regarding the model completeness and the relationship expressiveness (Quinn and McArthur 2021). However, since the cooperation of ASHRAE's BACnet Committee (Haynes 2018), the two systems have been continuously updating versions, absorbing the advantages of each other. Therefore, this paper compared the latest versions of Haystack (Version 3.9.10, referred to as Haystack 4) and Brick (Version 1.2.0).

A Comparison of Brick and Haystack
The design of Brick took the completeness of all information, the expressivity in relationships, the usability for various users, and consistency along with the model processes, and the extensibility for more concepts.
The expression of relations at all levels is consistent in Brick (Brick Schema 2021).   Figure 2 is an example of a chiller in Haystack. It has adopted Web Ontology Language (OWL) and RDF for ontology. The Namespace, Def are declared as Point 3 in the above summary.
It is needed to notice that the chiller in Turtle format referred to the classes defined in Zinc.
The new version shows three real cases of the Haystack application, which is helpful for novices to understand and develop the protocol. Haystack has added new features to compensate for its inconsistency. However, Namespace, Def, Subtyping, Reflection, and Relationship have functional overlaps. For instance, water is a subtype of fluid, which can be described as isPartOf in Brick. It is unnecessary to classify tags as libraries.
The other issue is that the new version failed to provide a tutorial for starters, nor a testbed for education. Haystack provides all the tools to the users, regardless of their ability and knowledge in the field. Therefore, considering the model consistency and the ease of use of the application, the semantic development of the VRF module is based on Brick.

The role of Brick Schema in BMS
The relationship defined in the Brick model represents the connection between the datasets. As shown in Figure 3, the role of Brick is to create reliable connections in the data lake, assisting the digital twin process from devices to application interfaces in BACnet.   Since the status of the device changes considering their working conditions, the development of the VRF Brick module used the device roles during cooling mode as the device names and the positions to represent the sensors. The data transferred from the devices can distinguish their working condition. The development work covers everything from the definition of refrigerant to the definition of VRF equipment. As for the sensors such as frequency and pressure, Brick has already included sensors for HVAC, which the developed Brick VRF can also use. Figure 7 showed some of the created modules. After compiling, the Brick VRF module can be applied for projects.   The internal structures can also be described semanticaly. In Figure 10, the status of valves can determine the working conditions, the on-off status of can determine whether the working mode is cooling, heating or both.

BMS server with Brick VRF module
A server with databases to store the building semantic model and building operation data is deployed. The server is developed upon Brick-server (Gabriel Fierro 2019; Schneider et al. 2020). As illustrated in Figure 11, the sensor data goes to databases through a gateway. The building model with VRF systems is stored in the databases, data labeled with timestamps are stored in timescale databases corresponding to their points in the model. The server in Figure 11 takes advantage of Brick Schema in portable building analysis with various buildings (Gabe Fierro and Culler 2017; Koh et al. 2018). Clients can query the database for building relationships, as well as fetch data for operation analysis. Fig. 11. BMS data server with Brick VRF module

Validation
To verify the Brick VRF module, an experimental model is built for validation. Figure   12 illustrates the internal relationships of the apartment building. Apart from sensors, an HVAC zone fed by a VRF system is also included.  . The test sends queries to the server, and the server will filter and return the data of the objects that meet the requirements. The advantage of this server is that the BMS data management is no longer limited to a single building, and the building data that fits the same ontology standard can be queried and analyzed, instantly. Figure 14 showed the test results, and energy balance analysis was done simultaneously when getting energy and outside temperature data from the query.

Application
After the Brick VRF module and the server being validated, they are used for a building sector in Shunde. The general layout is illustrated in Figure 15, the sector has two HVAC zones, each zone has a VRF system, each VRF system has one indoor unit and three outdoor units.   The following images are used as a demonstration of building energy analysis. When querying for outside temperature and energy meter records, the server will return data of both VRF systems in Office 1 and Office 2, and data analysis for both rooms can be done at the same time. The results of energy baseline analysis for Office 1 and Office 2 are in Figure 18. Although the overall trend of the forecast results is greatly affected by February and the accuracy needs to be improved, the application in this block shows the availability of the Brick VRF module and the data server. The application case is to evaluate the server's ability to handle various data linked by the model in Figure 13. The results of the query and analysis indicated that data management from a hosting server backed by Brick became reasonable to machines and humans. Besides storing data and hosting queries, because of the information connections being guided by the Brick model, the application can run simultaneous data analysis for different spaces.
However, because the data used in the application has a unified standard, and the building operation data are still stored in a single database, it does not effectively verify Brick's role link in the massive data lake. This problem needs further research in the future.

Conclusions
In this paper, the Brick VRF module is developed and applied to solve the problem that there is no Hydrofluorocarbon defined in Brick and how to classify VRF equipment in Brick.
This paper presents the VRF module to extend Brick Schema and verifies the Brick VRF module. Then, the model and the service framework are developed and applied for a building sector in China. The application case demonstrates the advantages of Brick in managing multi-building datasets. The VRF module of this paper provides a solution for the expression of the VRF system in the building semantic web.
However, it should be mentioned that the development of the service framework in this paper only uses brick for storage and query, and its advantages in multi-building massive data management need to be further explored, which can be used as future research work.