Abstract
Several OWL ontologies have been developed for the AEC industry to manage domain-specific information, yet they often overlook the domain of building services and HVAC components. The Flow Systems Ontology was recently proposed to address this need, but it does not include HVAC components’ size and capacity-related properties. Also, despite their strengths in representing domain-specific knowledge, ontologies cannot efficiently identify poor data quality in BIM models. A four-fold contribution is made in this research paper to define and improve the data quality of HVAC information by (1) extending the existing Flow Systems Ontology, (2) proposing the new Flow Properties Ontology, (3) proposing an HVAC rule set for compliance checking, and (4), moreover, we use Semantic Web technologies to demonstrate the benefits of efficient HVAC data management when sizing components. The demonstration case shows that we can represent the data model in a distributed way, validate it using 36 SHACL shapes and use SPARQL to determine the pressure and flow rate of fans and pumps.
Keywords
Introduction
A document-centric AEC industry
Architecture, Engineering and Construction (AEC) projects have become more technically complex and involve many stakeholders that must exchange information to complete a project successfully [33]. Since the Building Information Modeling (BIM) methodology was introduced in the early to mid-2000s [48], the AEC industry has experienced improvements in coordination and communication between project stakeholders and digital tools. The BIM methodology aims to achieve a more collaborative workflow and addresses the need for a Digital Information Hub [68]. It provides a method for managing structured, accessible, and reliable building data to represent the physical and functional characteristics of a 3D building model. Current BIM applications have improved the workflows across the building life cycle and typically include 3D modelling. For that reason, the use of BIM is focused on phases of the building life cycle where 3D modelling is a requirement [21]. Today, BIM methodology is mainly based on a document-centric approach in the AEC industry, leading to poor data management across the building life cycle, disciplines, and digital tools [16]. Data is often outdated and not in sync with the actual building model, for which no live access is available.
The Industry Foundation Classes (IFC) is currently the standard format of building information and has been applied to exchange the needed information among stakeholders, mainly in a file-based or document-centric approach. Extending the IFC schema with new domain-specific knowledge is difficult due to its monolithic structure and complexity [43]. In addition, the schema does not describe cross-domain information such as occupancy data, meteorological data, data from building automation and control systems (BACS), nor information that links the different domain information to each other [21].
Linked Data & Semantic Web
The World Wide Web Consortium (W3C), with its participants consisting of academic and industrial partners, has developed open data standards for software developers to support the shift from a “Web of Documents” to a “Web of Data” [23]. They have developed the Semantic Web Technologies consisting of Resource Description Framework (RDF), RDF Schema (RDFS), Web Ontology Language (OWL), SPARQL Protocol and RDF Query Language (SPARQL), as well as Shapes Constraint Language (SHACL). It is a framework that enables sharing, accessing, conforming, and linking data over the web in a machine-interpretable format [56,57].
Interlinked domain-specific ontologies.
Contrary to the IFC schema, which has well-known limitations such as limited expression range, difficulty partitioning of information, and multiple ways of describing the same information, the W3C suggests more modular, polylithic, and simple data formats, also called ontologies, that can be interlinked and easily extended over time [29,40,43]. Figure 1 shows the concept of interconnected ontologies, and it can be seen that the domain-specific ontologies can be separated as smaller graphs and linked with other ontologies. An ontology does not need to cover an entire domain, such as HVAC systems. It can also cover minor subdomains for HVAC, such as representing different component types and their properties alone or the connectivity of HVAC components and their relations to systems and subsystems. Developing smaller ontologies that target one building domain will yield a practical and flexible way of modelling knowledge when combined [21,58].
In this context, the World Wide Web Linked Building Data Community Group (W3C LBD CG) has defined and shared a set of ontologies like Building Topology Ontology (BOT) [42], Flow Systems Ontology (FSO) [27], TUBES System Ontology (TUBES) [37], Property Set Definition Ontology (PROPS) [7], and Product Ontology (PRODUCT) [67] for the AEC industry. While FSO describes the energy and mass flow relationships between systems and their components and their compositions [27,37], it lacks system components’ capacity- and size-related properties. A key aspect here is whether such properties need to be added directly to the FSO ontology or can be kept separate, e.g. in its own module or ontology. In Section 3 we argue that the best approach to create an ontology, called the Flow Properties Ontology (FPO), that includes only those properties and aligns it with other existing ontologies in the LBD CG context, in particular with the FSO ontology that focuses on HVAC domain.
Conforming domain-specific knowledge
Despite their strengths in representing domain-specific knowledge, ontologies cannot solve the problem that many BIM models are poorly modelled and lack building elements or metadata. Currently, poor data quality in building models contributes to faulty design decisions and downfalls in the information stream. Due to the increasing level of information, it is challenging to create sufficient BIM models [24,40,46,60]. Architects and owners can spend hundreds of hours manually assessing conformity [26]. Due to the time-consuming process and the need for high-performing BIM models, many research publications have addressed conformance checking. The most prominent publications on conformance checking of BIM models cover various frameworks, tools, rule languages, rule models, and rule engines [5,8,12,13,19,22,30,36,49,53,54]. As their data models rely on IFC or their rule models lack semantic expressivity, they all have limitations and cause poor query performance [28,51]. Soman et al. [55], Stolk and McGlinn [56], and Oraskari et al. [35] describe a promising approach to surpass the limitations of IFC and improve conformance checking. They use a Semantic Web approach with a data model written in OWL and a rule model written in SHACL to verify constraint violations. Soman et al. [55] applied the method to the construction field, while Stolk and McGlinn [56] applied the method to the geospatial field, and Oraskari et al. [35] to the energy simulation field. However, these publications do not describe how to validate an HVAC model with SHACL, nor do they apply the framework to a real-world large building project. In addition, we intend to develop a rule model written in SHACL for validating HVAC-related constraints.
Contribution
Considering the above, several innovations are needed. In fact, our research includes five contributions. Firstly, our research aims to extend FSO to support an alignment with the proposed FPO ontology. Secondly, we propose the FPO ontology itself to represent HVAC components’ capacity and size-related properties. Thirdly, we propose a set of rules to validate HVAC-related constraints. Fourthly, our work produces a demonstration environment for a real-world building project, showcasing how to conform a HVAC model using Semantic Web technologies. Lastly, the demonstration environment will showcase how FPO and the HVAC rule model can support the description and validation of hydraulics in HVAC components and the capacity of HVAC components.
Outline
The remainder of this article is structured as follows. Section 2 describes previous work on knowledge representation and rule checking related to buildings and systems. The presented work is limited to OWL-based data models and SHACL-based rule models. The development of FPO and extension of FSO are explained in Section 3. Section 4 outlines our framework and rules for validating HVAC-related constraints. We utilize a real-world building model in Section 5 to illustrate how FPO can represent capacity- and size-related properties and be used to design an HVAC device. Additionally, the real-world building model will be validated against our rule model in Section 5 where a process of four steps and a web application are introduced and applied to generate validation and capacity design results and display the results within a web interface. The validation results pinpoint the components or properties in the data model that violate our rule model, while the capacity results show the flow rate and pressure of each flow-moving device that is represented in the data model.The validation and capacity design results are discussed in Section 6, and conclusions are presented in Section 7. Table 1 shows the namespaces and prefixes used in this article.
Used prefixes and namespaces
Used prefixes and namespaces
Scope of the HVAC domain
The HVAC engineer is responsible for designing a building’s HVAC system. The purpose of an HVAC system is to provide building occupants with acceptable thermal comfort and indoor air quality. HVAC engineers must go through a series of steps to design an HVAC system, such as defining the distribution strategy for HVAC, defining the control strategy, calculating HVAC demand by zones, and determining the capacity and size of HVAC systems and their components. To determine whether an HVAC system is designed sufficiently, its cooling, ventilation and heating effects are compared with the building’s cooling, ventilation, and heating demands. The HVAC system is considered sufficient when the capacity exceeds the building’s demand. The HVAC engineer must design each HVAC component’s capacity individually since an HVAC system’s capacity equals the sum of its components. The HVAC component’s size is then determined based on its capacity. The HVAC engineer can choose a product from a manufacturer once the capacity and size have been defined. By the time all HVAC components have been designed, the HVAC engineer has completed the HVAC design process.
Since our research project seeks to represent and validate an HVAC system’s and HVAC component’s capacity and size-related properties in a Semantic Web context, Section 2.2 provides an overview of what research has been achieved in this field and what is missing.
System representation in a Semantic Web context
A number of ontologies have been proposed to handle data within the AEC industry since the early 2000s. The first significant contribution towards moving BIM data into the Semantic Web is the ifcOWL ontology. IfcOWL is an OWL representation of the IFC schema [6,59], and it is available at the buildingSMART website1
The next paragraphs present the ontologies that are relevant in the building service systems domain.
BOT describes the relationship between building zones and elements [44]. A zone can be a building, a floor, a space, or a group of spaces. The building can be connected to the floor level by asserting that an entity of
SEAS describes the relationships between physical systems [31]. There are three main modules in the ontology, namely, The System Ontology, The Features Of Interest Ontology, and The Evaluation Ontology. The Features Of Interest Ontology allows us to describe features of interest and their properties. A car, as an example, can be considered a feature of interest with a property called speed. Properties are either evaluated directly or through a qualified evaluation in the Evaluation Ontology. In a direct evaluation, a value is assigned to the property. A qualified evaluation needs to outline three categories: type, the context of validity, and provenance data. The System Ontology describes the systems and the relationships between them. There are three levels of connectivity: between systems, connections, or connection points. The SEAS ontology focuses primarily on electrical systems but can also be used to represent higher-level building services systems [31]. Yet, it does not describe any building service components or their relationships to building service systems.
Building service components are included in the Brick ontology [4] and the SAREF ontology [9] at different conceptual levels and scopes. The emergence of semantic modelling in building systems has been significantly influenced by the collaboration and development of standards and frameworks like Brick, Project Haystack, and American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) Standard 223P [3].
The Brick ontology describes sensor points and their relationships to physical, logical, and virtual assets in buildings. It consists of a core ontology to describe fundamental concepts and their relationships and a domain-specific taxonomy. The ontology focuses on sensor points and their relations to location, equipment, and resource [4]. Relating a sensor point to a location expresses in which area of the building the sensor point is located. It can be located in a room, on a floor, in a duct. Relating a sensor point to specific equipment expresses how the sensor point controls the system or component. For example, take a room temperature sensor positioned in a room. The room temperature sensor regulates how much air an Air Handling Unit (AHU) must supply to the room. Lastly, the resource is the medium being measured and regulated by the sensor point and equipment. For example, the medium of an AHU is the air that is being supplied to a room.
ASHRAE Standard 223P, developed in collaboration with Project Haystack and the Brick initiative, aims to standardize semantic modeling in building systems. This standard represents a significant step towards unifying the approach to building data semantics, building upon the foundational work of Haystack tagging and Brick data modelling concepts [3].
The SAREF Smart Appliances Reference ontology is a reference ontology for smart appliances (devices) [9]. It aims to bring meaningful interactions between Internet of Things (IoT) devices in various domains. There are currently 13 extensions to the core ontology. SAREF4SYST is based on the concepts of
However, while Brick, SAREF, and the initiatives leading to ASHRAE Standard 223P have significantly advanced semantic modeling, particularly focused on the operational phase of the building life cycle, they present limitations in certain areas. Specifically, these frameworks and standards primarily revolve around sensor points, leading to a notable exclusion of passive components, such as pipes and ducts, or their properties.
An OWL ontology that is similar to the SAREF4BLDG ontology, but does not include any building topology to avoid semantically overlapping ontologies, is the Mechanical, Electrical and Plumbing (MEP) ontology.2
FSO focuses on the design and operational phase of the building life cycle [27]. It describes the mass flow and energy relationships between systems and components and the composition of such systems [27]. FSO gives the ability to connect both passive and active components to systems and subsystems. For example, a heating system can include a supply and a return system as subsystems. A segment or fitting can be related to a supply or return system. A component can also be connected to a supply and return system, such as a heat exchanger. A segment can supply or return fluid to another component based on what system it belongs to. Unlike Brick and SAREF ontologies, FSO only represent higher-level components such as flow-moving devices or flow-controlling devices (also included in the MEP ontology). The taxonomy of building service devices for all four ontologies is based on the IFC taxonomy. However, FSO does not represent both active and passive components’ size- and capacity-related properties. Without that representation, HVAC engineers cannot design an HVAC system nor an HVAC component during the design phase using FSO.
FPO and an extended version of FSO are introduced in Section 3 to fill this research gap and describe the size- and capacity-related properties of both active and passive components within the design phase. Ontologies are mainly used to represent domain-specific knowledge. To check whether a BIM model lacks building elements or metadata, we need a rule language. Section 2.3 describes which rule languages exist and what research has achieved in this area in a Semantic Web context.
This overview of existing ontologies in the AEC industry, including ifcOWL, BOT, SEAS, Brick, SAREF, and others, aims to highlight both their strengths and limitations in relation to HVAC system representation. These ontologies lay the groundwork for our further research, where we introduce FSO and FPO. Building upon this existing knowledge base, FSO and FPO take a step further to address specific needs in HVAC system design. By focusing on capacity- and size-related properties for both active and passive components, FSO and FPO fill critical gaps left by these ontologies. This contribution is crucial for enabling more detailed and accurate design and compliance checking of HVAC systems in the building design phase.
Several prominent rule languages have been developed by the W3C. In 2004, the W3C introduced the Semantic Web Rule Language (SWRL) as a member submission.3
Similar to SWRL, the Rule Interchange Format (RIF) introduced in 2005 by W3C allows rules to be expressed in XML syntax. In order to enhance interoperability between rule languages, RIF was designed to be the standard exchange format for rules on the Semantic Web. As of today, RIF consists of 12 parts, including RIF-core, which is the core of all RIF dialects [32,64].
Notation3 (N3), is an assertion and logic language that supports expressing RDF-based rules. It was introduced in 2011 by W3C as a team submission to extend RDF by adding formulae, variables, logical implication, and functional predicates, as well as to provide an alternative syntax to the XML syntax that SWRL and RIF use. By using shortcuts and syntactic sugar, it is able to simplify statements in the form of triples [62].
The SPARQL Inferencing Notation (SPIN) was introduced by W3C in 2011 as a member submission and has become a de facto industry standard for describing SPARQL rules and constraints. The key feature of SPIN, compared to SWRL, RIF, and N3, is the ability to specify constraints using SPARQL queries. In this way, property values can be calculated based on other properties, or a set of rules can be isolated for execution under certain conditions. It is also possible to use SPIN to check the validity of constraints based on the assumption of a closed world [63].
SHACL is the successor to SPIN and was published as a W3C Recommendation in 2017 [20,65]. A higher status has been granted to SHACL by W3C in comparison to SWRL, RIF, N3 and SPIN. Distinguished from other Semantic Web technologies, SHACL is based on the Closed World Assumption (CWA). This approach means that in data validation, SHACL considers anything not explicitly stated in the dataset as false or non-existent, focusing on validating data against specifically defined constraints within this “closed world.” This feature of SHACL makes it particularly effective in scenarios where explicit and complete data validation is essential [66]. As a result, SHACL has become the web standard today for validating RDF graphs. SHACL is heavily inspired by SPIN, but it offers far more flexibility in defining target constraints. SPIN is limited to classes, while SHACL can be applied to classes or sets of nodes by various target mechanisms, including customized targets. Furthermore, SHACL advanced features allow validation of more complex constraint types, such as sub-graph pattern- and conditional validation. SHACL contains two major components:
A data model containing domain-specific knowledge.
A rule model consisting of user-defined constraints. User-defined shapes can be node shapes or property shapes. Node shapes specify constraints on target nodes, while property shapes specify constraints on target properties and their values.
By separating the data model and rule model, SHACL follows the Business Rule Management Systems (BRMS) principle of decomposing knowledge into logic and data, enabling them to be independently manipulated [55]. In addition, SHACL outputs an RDF graph with validation results, which describes whether a data model passed or failed a given rule set.
The following section highlights the research gap based on an overview of recent research on applying SHACL to perform conformance checking within the AEC industry.
Stolk and McGlinn [56] demonstrated how ifcOWL can be validated using SHACL. The authors showed how
Hagedorn and König [20] developed an approach for compliance checking linked building models. The proposed method implements the four steps mentioned by Eastman using Semantic Web technologies. Using the IFC2RDF converter, the authors converted an IFC schema into ifcOWL. Their rule model involved a set of rules to validate the path between an identifier of a link and the original identifier. In order to validate their data model against the rule model and receive a validation report, they used the W3C SHACL Test Suite.
To define and check complex and dynamic scheduling constraints in construction, Soman et al. [55] developed a linked-data-based constraint-checking approach utilizing Semantic Web technologies. The approach was implemented through a web application that validated construction scheduling violations using different types of constraints. The pySHACL library was used to define and validate SHACL shapes, and the RDFlib library was used to design and store a RDF graph. They used IfcOWL and LinkOnt to capture the model information of a real-building model.
Oraskari et al. [35] defined rules within the energy simulation field for validating windows of specific sizes, checksums of properties, and alignments of BOT classes and properties. They validated two data models against each other in order to align BOT classes and properties with ifcOWL. The IFC schema of a conceptual building model was converted to ifcOWL and BOT using the IFCtoLBD and IFC2BOT converters. The rule modelling, validation and reporting were performed using the TopBraid SHACL Application Programming Interface (API).
While previous studies have utilized SHACL in various domains, none have specifically focused on HVAC systems in BIM models. This study introduces a SHACL-based rule model tailored for the HVAC domain, utilizing lightweight ontologies like FSO and the newly proposed FPO to define HVAC systems and components within a data graph. This targeted approach not only meets the unique design requirements of HVAC systems but also ensures the integrity and reliability of HVAC data in BIM models. Crucially, this study contributes to bridging the information gap in HVAC information management by developing a SHACL-based HVAC rule model. Such an advancement is key for enhancing HVAC data integrity in BIM environments, thereby addressing a critical need in the AEC domain.
Flow properties ontology
FPO is developed as an extension to FSO [27] to represent FSO component’s capacity and size-related properties. The decision to develop FPO as an extension to FSO instead of integrating its concepts and relationships directly into FSO is driven by the desire to maintain simplicity and ease of use in the core ontology. By keeping FSO minimalistic and general, it remains accessible and adaptable. FPO adds the necessary depth and detail for capacity and size aspects in certain HVAC subdomains without complicating the core system (FSO). This approach ensures that FSO and FPO can evolve and adapt over time with ease, are straightforward to maintain and update and remain user-friendly for all levels of expertise. This design philosophy mirrors that of the SAREF ontology [9], which employs a core ontology for fundamental concepts, expandable through specific modules for different areas.
FPO contains 50 classes, 50 object properties and 6 data properties and has a Description Logic expressivity of
It is necessary to know the HVAC component type to describe its properties. A property of one HVAC component may differ from another, and the data type or unit of one property may vary from another property. A pump has different properties than a fan, and the flow rate can be expressed in liter per second or cubic meters per hour, which is different from a ventilation fan. An elbow can differ in properties from a tee by having an angle, even if both are fittings. Moreover, a tee has three flow ports, and an elbow has two flow ports. Conceptually, Fig. 2 illustrates how a component can have a property and the property a value. As there are two steps between the component (Type / Object) and the value, this property modelling approach is a Level 2 (L2) property modelling approach, as defined by Bonduel and Pauwels [38].
Relationship between components, properties, and property values.
It is possible to represent buildings, spaces, and their relationships with systems and components using FSO and BOT. Adding FPO, the representation can identify whether a particular system or component is able to heat, cool, or ventilate a specific building or space.
The following subsections provide a more detailed description of FPO. To determine the scope of the ontology, Section 3.1 lists a set of competency questions. In Section 3.2.2, FSO is extended with medium-level components to represent fluid movements between components. Section 3.3 reviews FPO classes and their properties. Finally, reasoning examples will be enabled in Section 3.4. Both the extension of FSO and the development of FPO are made available on GitHub.4
Competency questions in Table 2 are central to evaluating the practical applicability and relevance of the FPO in the field of HVAC engineering. These questions were formulated based on the typical needs encountered by HVAC engineers. Each question highlights a critical aspect of the HVAC design process:
Competency questions
Competency questions
The scope of the ontology, as outlined by these questions, is further validated in Section 5 through SPARQL queries.
Connection between components
FSO represents the energy and mass flow relationships between systems, their components, and their composition. However, the current version of FSO cannot express the magnitude of these flows. Real-world components contain fluid in motion, flowing in and out through openings and passages, i.e. ports, which vary considerably in size, impacting pressure drop and flow rate, e.g. capacity. Without representing these size and capacity-related properties, FSO cannot fully capture the nuances of fluid dynamics, crucial for accurate HVAC component and system design. As a result, incorporating
The concept of relating a
A segment partitioned with ports connecting to a fitting through its ports.
A relationship can be described among systems and components as shown in Fig. 4. The components share the same
Current and extended taxonomy of FSO with connection points.
The proposed extension to FSO makes it capable of representing components and interfaces in multiple ways, which adds some flexibility. The definition of the mentioned classes and relationships in this section is defined as follows:
Currently, FSO represents eight high-level component types. For several reasons, we must subdivide the eight high-level component types into 19 medium-level components. For instance, the hydraulic sizing of a pump or a fan is different. The sizing of a pump includes the pressure drop from both supply system components and return system components, but the sizing of a fan only includes the pressure drop of either supply or return side. We have to define the types explicitly when performing hydraulic calculations.
Often components lack the required properties to perform a hydraulic calculation. For example, if an elbow does not have a specified angle, we will not be able to differentiate between an elbow or transition since they both are represented as a
A class hierarchy of current and extended FSO components.
FPO provides 6 data properties: value, unit, abbreviation, design condition and curve. They can be used to relate an entity literal to an entity class. Combined, the 50 classes, 50 object properties and 6 data properties represent the size and capacity of the FSO components.
In property modelling, there are different levels of complexity. Level 1 (L1) property modelling is a straightforward approach where properties are directly linked to a component. For instance, in an L1 model, a property like
Describing the relationship between an
However, Fig. 6 demonstrates a more complex approach, where we apply the Level 2 (L2) property modelling approach as defined by Bonduel and Pauwels [38]. In this approach, an
The adoption of the L2 approach in FPO is driven by the need for structured flexibility and scalability in representing HVAC properties. This model allows each property, such as
Semantic Web technologies enable deductive reasoning as well as explicit assertions. A few examples of how FPO and the extended FSO allow for reasoning are presented in this section. Every object property in FPO is assigned a domain and a range. For example, the attribute
An
Deducing that the segment feeds fluid to the fitting as a port of the segment supplies fluid to a port of the fitting.
In addition to the specific reasoning capabilities within FPO, it’s important to note how the ontology operates under the Open World Assumption (OWA). This means that if FPO lacks data on a specific property, such as the flow rate of a pump, it doesn’t presume the information to be non-existent; rather, it’s understood as not currently known or included in the ontology.
When new information becomes available, like a previously unknown flow rate, FPO can incorporate this data seamlessly, allowing the ontology to adapt and evolve over time. This reflects the dynamic nature of HVAC system properties and their changing characteristics.
In practice, when querying a triplestore using FPO, missing data is presented as unknown rather than non-existent, conforming to the principles of the OWA. This approach ensures a realistic and dynamic representation of HVAC components’ properties, essential for accurate modelling and analysis in ever-evolving HVAC environments.
The HVAC rule model, comprising 36 shapes and 122 constraints, is specifically designed to pre-validate HVAC data models to ensure they contain all necessary information for hydraulic calculations. Accessible on GitHub,5
Building upon this foundation, Eastman et al. [15] propose a four-step manual approach for rule-based compliance checking. This methodology is significant as it enables us to apply targeted corrections bypassing the time-intensive and error-laden process of manually inspecting large and complex BIM models. The steps include:
Rule interpretation: Human-readable rules are converted into a machine-interpretable format that contains the information needed to be checked in the correct format, also known as the rule model.
Building model preparation: Building information is converted into a machine-readable format, also known as the data model.
Rule execution: The data model is validated against the rule model.
Rule check reporting: A validation report describing whether the data model has passed or violated any constraints.
While this approach provides a comprehensive framework for compliance checking, it remains primarily passive, identifying whether constraints are met or violated. To address this, Solihin et al. [52] introduce a proactive fifth step for automatic correction, empowering users or systems to not only be notified of violations but also to receive corrective data, with options for automatic or manual implementation.
Furthermore, Solihin et al. [52] suggest categorizing rules based on their complexity, ranging from 1–4:
entities and attributes are queried and checked against a single value.
additional values are calculated (e.g. distance) and checked.
additional geometry is created in order to calculate spatial relationships.
problem solutions are calculated, and new data is created.
This section will demonstrate how a SHACL-based rule can be designed for each complexity level, tailored specifically to the HVAC domain.
In hydraulic calculations, it is essential to know the location of each pipe segment in relation to upstream and downstream HVAC components, as well as its roughness and length. Understanding the placement of HVAC components in relation to other components helps determine how fluids like air or water move through the system. “Upstream” refers to components that come before the pipe in the fluid’s flow direction, while “downstream” refers to those that come after. The roughness and length of the pipe are also crucial for calculating how efficiently the fluid moves through the system. The shape
An fso:Pipe must have exactly two flow ports.
A pipe must feed fluid to exactly one component.
A pipe must be fed with fluid by exactly one component.
A pipe must be connected to exactly one system.
Exactly one property of material type must be present in a pipe.
Exactly one property of length must be present for a pipe.
Exactly one property of roughness type must be present for a pipe.
In Listing 1, only the first constraint is expressed in SHACL. The remaining 6 SHACL constraints are made available on GitHub.6
A SHACL shape to constrain the number of
HVAC systems and their components must be designed to provide sufficient heating, cooling, and/or ventilation to buildings. For example, an HVAC terminal is designed correctly if its capacity to heat, cool, and ventilate a space exceeds the space’s demand. With the following constraint, we demonstrate how the capacity of a supply air terminal can be compared with the supply airflow demand of a space:
The supply air terminal capacity should be higher than the space’s required supply airflow demand.
The rule is expressed in a single SHACL shape, as shown in Listing 2, and the constraint belongs to the shape
The listing shows a SHACL shape to constrain the capacity of a supply air terminal versus the supply airflow demand of a space
The pressure drop in pipes affects the economy of building projects, the material’s lifetime and the energy consumption of HVAC systems. A high-pressure loss will result in a lower cost price, a shorter lifetime, and higher energy consumption. As a result, most HVAC engineers apply guidelines to their design, e.g. a maximum pipe pressure loss of 100 Pa/m. This guideline or rule cannot be conveyed through explicit information. Calculations and derived information are also required. The complexity level of the shape
The pressure drop of a
Listing 3 shows the rule expression in SHACL. The pressure drop in pipes is not explicitly defined in Pa/m in FSO or FPO. We can, however, implicitly find the information using a SPARQL constraint. Our SPARQL-based constraint contains a SPARQL select query. The select query returns all instances of
A SHACL shape to constrain the maximum pressure drop of each
During the HVAC design process, HVAC components are often oversized or undersized due to limited time. Rather than just creating a rule that notifies whether HVAC components are right-sized passively, we will generate new data actively and add it to the model. By increasing the diameter of the pipe, we can decrease the pressure drop. That is precisely what Listing 4 is doing. Listing 4 is an inference rule expressed in SHACL. Using a SPARQL construct query, the pipe diameter is increased based on the material type and standard manufacturer size. The dimensions are limited to the material type PEX7
A SHACL shape to increase the size of a
This section aims to demonstrate how capacity and size-related properties within the HVAC domain can be represented and validated for a real-world BIM model. The use case process is illustrated in Fig. 8.
The process of performing conformance checking and design calculations for an HVAC model.
The first step of the process is to create a data graph and shape a graph. As the shape graph is already produced in Section 4, it does not require further processing and can be used as-is.8
Combining multiple ontologies to represent building, spaces, systems, HVAC components, their properties and their relationships.
In the second step, a rule execution process will be performed to check the shape graph against the data graph. The data graph will be manually corrected if any constraints are violated during rule execution. Depending on the violation type, manual correction can be achieved at three levels: BIM model, parser, or data graph. In cases where we do not want to modify the BIM model, we can use SPARQL on the data graph or add the information through the parser.
When the rule execution conforms, we can proceed to step 3. This step involves hydraulic calculations for ducts, pipes, and fittings to determine each distribution component’s pressure drop and fluid velocity. These hydraulic results will then be materialized in the data graph, facilitating a second conformance check. This check involves comparing the shape graph against the data graph, now including the hydraulic calculations. Whenever a constraint is violated, an HVAC rule at level 4 in complexity from the shape graph will be used to correct the violation.
When the rule execution conforms, we will have all the information necessary to size the flow-moving device. Step 4 will therefore involve calculating the capacity of each flow-moving device, represented in the data graph. After the flow-moving devices’ capacities have been calculated, the result is given, and the process ends.
We developed the Semantic HVAC tool to perform the process shown in Fig. 8. The web tool has a microservice-oriented system architecture and contains four layers, which is illustrated in Fig. 10. The source code of the Semantic HVAC Tool and the material used to perform the process shown in Fig. 8 is made available on GitHub.9
The system architecture of the Semantic HVAC Tool.
The presentation layer handles the user interface logic and displays data on the page. The Graphical User Interface (GUI) relies on React components to improve page rendering [45]. Using the GUI, users can perform conformance checking, perform hydraulic calculations, calculate the capacity of flow-moving devices, and view the results. The user has to initiate the conformance checking and calculations in the right order, as shown in Fig. 8. It is, therefore, necessary for the user to initiate the conformance check first. The user must correct all violations manually if any exist. If any violation exists, the GUI will not allow the user to perform the hydraulic calculation. Using this method, we ensure that the data model contains all the information we need to calculate the hydraulics. The same applies to the capacity calculation of flow-moving devices. If any violations occur after the second conformance check, the GUI will not allow the user to initiate the flow-moving device calculation.
The GUI displays the conformance check results in two different tables. Based on the type of HVAC component, the HVAC system, and size and capacity properties, the first table shows the number of violations. The first table is interactive. By selecting a specific HVAC component type in the first table, the GUI will display the second table. The second table lists the violations for that specific HVAC component in more detail, including the instance ID, constraint type, and violation description. Additionally, the GUI shows the results of the flow-moving device calculation in a table. The table displays the type, ID, flow rate, and pressure of each flow-moving device.
Communication layer
The orchestrator handles the communication between the service components in the Semantic HVAC Tool via HTTP requests.
There are two ways to communicate between services: decentralized and centralized. Decentralized communication allows microservice components to communicate directly with each other. In central communication, microservices will communicate through an orchestrator service. As illustrated in Fig. 10, we have implemented a central orchestrator to handle the communication between the presentation layer, the business layer, and the database layer. The orchestrator is developed as an ExpressJS server [17] in NodeJS [34]. When the user initiates the conformance checking, the following communication will happen:
the client requests conformance checking results from the orchestrator.
the orchestrator requests conformance checking results from the rule service.
the rule service sends a rule model expressed in turtle format to the orchestrator.
the orchestrator sends the rule model to the database.
since the database already stores the data graph, it performs the rule execution and sends the conformance-checking results expressed in JSON-LD to the orchestrator.
the orchestrator sends the conformance-checking results to the client.
the client displays the conformance checking results in two tables.
Similar to the conformance checking, the orchestrator handles communication between the different services when performing hydraulic- and flow-moving device calculations.
Business layer
The business logic is spread over multiple microservices in the web application. We have divided our logic into two microservices: the capacity service and the rule service, as shown in Fig. 10. Rule logic is handled by the rule service, while the capacity service handles HVAC design logic. The rule service consists of two functions. When requested, the first function provides a shape graph in turtle format, while the second function performs an automatic conformance check and produces a validation report in JSON-LD format.
The capacity service has one function. When requested, it performs a hydraulic calculation and provides the pressure drop result for each distribution component, which is of type
Database layer
The database layer consists of a Jena Fuseki server [2] that stores RDF data. The microservices in the business layer share the same database to access information from different domains easily. Jena Fuseki has SPARQL, SHACL, and Update endpoints. The SPARQL endpoint retrieves data, while the Update endpoint inserts, deletes, or updates data.
For example, when the user initiates the flow-moving device calculation, the client requests a list of flow-moving devices from the orchestrator. The orchestrator then requests three SPARQL queries.10
The parser11
To showcase the tool in use, we used a BIM model of a real-world building located in Sorø, Denmark. The building is a primary school constructed in 2017 and named Frederiksberg Skole. Frederiksberg Skole has a gross floor area of 6970 m2 and is divided into a northern building and a southern building. Each building has three-floor levels, as shown in Fig. 11. The original BIM model has been modified by Seeberg and Tangeraas [50] to include only the northern building and its heating and ventilation system. It has 86 rooms, each heated with radiators and ventilated with supply and extract air terminals. Both systems are located in the basement of the northern building. The results of parsing Frederiksberg Skole as a data model, performing two conformance checks, calculating the hydraulics and designing flow-moving devices with the Semantic HVAC tool are presented in this section.
The illustration shows the floor plans of Frederiksberg Skole in Sorø, Denmark. The south building is marked with red, while the north building is marked with blue [50].
The process of serializing Frederiksberg Skole from Revit to the Semantic HVAC Tool took 17.1 seconds to complete. Moreover, it took the Semantic HVAC Tool 8.3 seconds to store the data model of 369044 triples in the database. The triples are also made available on GitHub.13
In the conversion process from BIM to the ontologies, we achieved comprehensive coverage with varying degrees of direct mapping and manual processing:
BOT:
FSO:
FPO:
The table shows the amount of HVAC components, systems and size- and capacity-related properties in the data model
Overall, the conversion process was marked by a high level of direct mapping for most elements.
The process of validating the data model against the rule model took 3.1 seconds to complete. Table 4 shows the results of the first conformance check. For example, Table 4 shows that instances of type
Results of the first conformance check, showing the number of violations, based on HVAC component type, HVAC system and size- and capacity-related properties. Note: for components not listed, all validation rules were successfully passed
Results of the first conformance check, showing the number of violations, based on HVAC component type, HVAC system and size- and capacity-related properties. Note: for components not listed, all validation rules were successfully passed
In the client interface, accessing Table 5 is achieved by selecting the
Results of the first conformance check, showing the first two results of fso:System violations in details
All 32 violations were corrected in the data graph by performing the SPARQL update query shown in Appendix B directly in the Jena Fuseki Server. The query deletes all
The remaining violations were corrected manually in the BIM model, parser, and data graph, which resulted in an empty validation table. A blank validation table at this stage indicates that the data graph conforms, and we have completed step 2 of the process illustrated in Fig. 8.
Performing the hydraulic calculation on Frederiksberg Skole took 5.4 seconds. The violation results of the second conformance check are shown in Table 6. It can be seen that instances of
Results of performing the second conformance check, showing the number of violations, when the hydraulic results are added to the data graph. Note: for components not listed, all validation rules were successfully passed
Results of performing the second conformance check, showing the number of violations, when the hydraulic results are added to the data graph. Note: for components not listed, all validation rules were successfully passed
Selecting
Results of the second conformance check, displaying the first two results of
In the GUI, users can address all 14 violations using an interface element labeled’Solve all violations’. This element, upon engagement, executes a predefined SPARQL query, facilitating the correction of these violations directly within the data graph, thus eliminating the need for manual editing in the BIM model. The SPARQL query used is detailed and accessible on GitHub.14
Since we have performed the rule execution and hydraulic calculation, we are now ready to calculate the capacity of each flow-moving device represented in the data graph. The results of the flow-moving device calculation are shown in Table 8. It took 87 seconds to calculate the total amount of flow rate and pressure for each flow-moving device using three SPARQL queries and to display the results in the flow-moving device table. Two fans and one pump are shown in Table 8 as flow-moving devices. Table 8 provides the component ID, flow rate, and pressure for each
Flow-moving device results showing the type of each flow-moving device, its component ID, flow rate and pressure
Flow-moving device results showing the type of each flow-moving device, its component ID, flow rate and pressure
This section describes the achievements, limitations, and future work.
Achievements
This work introduces fundamental advancements in managing and ensuring the compliance of HVAC information during the building design phase, using Semantic Web technologies. The achievements in this domain are:
Limitations
Limitations in manual corrections due to varying expertise
The process outlined in Fig. 8 uncovers a significant limitation in real-world applications due to the varying coding expertise among HVAC engineers. These engineers, while proficient in their domain, often lack the specialized knowledge required to create SHACL-based rules. Their strength is in developing HVAC-related rules in a human-interpretable format. However, translating these into machine-interpretable formats like SHACL necessitates the involvement of Semantic Web experts who possess the technical skills for accurate translation and implementation. Furthermore, HVAC engineers’ ability to perform manual corrections varies, especially in technical tasks such as modifying parsers or adjusting data graphs, due to their limited coding skills and knowledge of the Semantic Web. This creates a need for collaboration with Semantic Web experts, who, despite their technical knowledge, may lack a deep understanding of HVAC systems to resolve violations independently. Therefore, HVAC engineers with limited coding capabilities may find it challenging to fully engage in implementing the process in Fig. 8, indicating a reliance on interdisciplinary collaboration.
Query efficiency
The rule execution is performing well since it took only 3.1 seconds to validate The HVAC rule model consisting of 36 shapes and 122 constraints against Frederiksberg Skole with 369054 triples. In contrast, it took 87 seconds to calculate the total pressure and flow rate of each flow-moving device, represented in the data graph using three SPARQL queries. Two of the SPARQL queries have a Filter Not Exists statement, which is responsible for the slow query performance. Using the Filter Not Exists statement, we iterate through all HVAC components in the graph and return only those with ports that belong to the same HVAC system. Iterating through all HVAC components and their ports slows down the query efficiency. This could be improved by replacing the Filter Not Exists statement.
Abstraction level of HVAC components
FSO is limited to eight high-level HVAC components and 19 medium-level HVAC components. In practice, it is possible to subdivide FSO further. For example, a pump can be subdivided into centrifugal pumps, positive displacement pumps. There are also several levels of centrifugal pumps. To retain FSO as a lightweight ontology, we did not nest further.
Geometry-based constraints
The data graph and shape graph we developed in our research does not represent HVAC component geometry and its geometry-related properties nor validate geometry-based constraints, such as separation distances between HVAC components and components from other domains or service distances, such as structural components. The delivery of BIM models with incorrect separation and service distances between HVAC components from the design phase to the construction phase is a common problem affecting a building project’s economy and schedule and should therefore be a focal point in further development.
Implications
This research significantly contributes to reducing the information gap in the AEC domain by approaching the problem from two directions: defining a specific ontology for representation and compliance checking of information. This dual approach ensures not only that the information is well-structured and specific to the needs of designing HVAC systems, but also that it is accurate, reliable, and compliant with the requirements.
Future work
The proposal for future work in this paper can be divided into three steps.
A literature review of geometry-related ontologies should be conducted first. If a sufficient geometry-related ontology doesn’t exist, an existing one should be extended, or a new one should be developed to describe the geometry and the relation between geometries.
Secondly, to represent separation and service distances for HVAC components, the geometry-related ontology should be interconnected with BOT, FSO, and FPO.
Lastly, a set of geometry-based constraints should be added to the HVAC rule model and validated against the data graph.
Conclusions
This paper presents a demonstration environment to represent and validate the composition of HVAC components, their systems, and their capacity and size-related properties using Semantic Web technologies. This paper aimed to:
Extend FSO to support an alignment with the proposed FPO ontology.
Propose the FPO ontology to represent HVAC components’ capacity and size-related properties.
Propose a rule model for the HVAC domain.
Produce a demonstration environment to show the conformance of an HVAC model.
Use the demonstration environment to show how FPO and the HVAC rule model can support the description and validation of hydraulics in HVAC components and the capacity of HVAC components.
We extended FSO with
Moreover, we developed an HVAC rule model that restricts the composition of HVAC components, their systems, and their size- and capacity-related properties. The rule model consists of 36 shapes and 122 constraints.
A four-step process and the Semantic HVAC Tool were developed to demonstrate how a real-world building model can be represented, validated, and used to compute hydraulic calculations and design the capacity of a flow-moving device. Frederiksberg Skole consists of 369054 triples and was used as the real-world building model. We managed to perform conformance checking twice. The first rule execution resulted in 372 constraint violations, and the second resulted in 14 constraint violations. Finally, using the conformed model, we performed hydraulic calculations and used the results to design the capacity of two fans and a pump, which were represented in the real-world building model.
Footnotes
Acknowledgements
This work was supported by EU-Interreg ÖKS “Data-baseret energiledelse i offentlige bygninger (Data-driven Energy Management in Public Buildings)”; the Innovation Fund Denmark (grant 9065-00266A); the Ramboll Foundation; and COWI A/S. We thank Sorø municipality for providing the BIM model for Frederiksberg Skole.