In the Building Information Modeling world, compliance checking of IFC models is an immense challenge. Many approaches such as Hard Coded Rule Checking, Query based Rule Checking, Rule Checking Approaches via dedicated rule languages (SWRL, Jess, N3Logic, etc., are being contributed to fulfil these requirements. In this paper, we present our research and development of Semantic BIM Reasoner (SBIM-Reasoner) tool for measuring and ensuring conformance of IFC models. SBIM-Reasoner implements multi-threading approach for embedding semantic querying and rule based approach for developing French building code compliance system. Various pre-processors (IFC2RDF Converter, Geometry Extractor, Rule Evaluator, etc.) run in different execution threads to build the underlying semantic repository providing faster rule checking and information retrieval from the triple store. When it finds non-compliant objects in the IFC model, it presents them to the end-user. With the knowledge graph over triplets, we have the freedom of extending our semantic IFC model, creation of newer vocabulary and formation of newer rules, concatenation of triplets to build rules with conditions and constraints over IFC data, dynamic reasoning over the triplets based on the initial data of IFC model, etc. We present encouraging results by various tests which were build using online IFC test models of various sizes and designs to test the performance of SBIM-Reasoner.
Several newer concepts, SPARQL rules (statements and materialization) are applied to enrich the underlying semantic repository as per demand of verification rules. Use of forward chaining mechanisms support the dynamic semantic verification for the future checks. We build several test cases comprise of different queries on different sizes of IFC models to evaluate our semantic approach. We discuss our experimental findings on many different analysis parameters; such as number of RDF triples in the RDF (turtle file) equivalent to IFC model, number of RDF triples in the semantic model (filtered turtle file) in the triple-store, estimated time taken by the conversion pre-processor and geometric pre-processor, etc. From the initial results, we conclude that SPARQL queries are flexible for retrieving data and perform validation in an optimized way giving better run-time as compared to the traditional approaches. The rest of paper is organized as follows. Section 2 presents related work. Section 3 presents our research and development of Semantic BIM Reasoner and its different sub-components. Section 4 presents our experimental analysis via using online building models. Section 5 concludes this paper and shows our future directions.
Many approaches and tools are being contributed to fulfil these requirements. Primarily Hard
Coded Rule Checking mechanisms via MVDs are used where building codes are assimilated
inside the application for the conformance checking of IFC models (Zhang et al., 2014). Tools
such as Solibri Model Checking
The main contribution in this paper is about the research and development of Semantic BIM Reasoner (SBIM-Reasoner) tool for measuring and ensuring conformance of IFC models. The idea is to formulize building code rule as a SPARQL query and then execute it on the building model, which is formulated as triplestore via forward/backward chaining mechanisms, to check the possibility of non-compliant elements in the building model. Figure 1 illustrates the top level architecture of SBIM-Reasoner. SBIM-Reasoner implements multi-threaded approach for embedding semantic querying and rule based approach for developing French building code compliance system. The main thread gets desired IFC models as input and triggers the Parallel Execution of Pre-Processsors for the execution of different tasks. Primarily it has three preprocessors, i.e., IFC to RDF Converter, Geometry Extractor, and Semantic Preprocessor which has further sub-components named IfcOWL Ontology sub-graph, SPARQL Rules, SPARQL Queries and TripleStore. Finally rule evaluator executes queries over semantic repository to checking and report the conformance report of IFC objects.
First thread executes conversion pre-processor to build the initial semantic repository based on
RDF triples equivalently converted from an IFC model. Figure 2 shows partial RDF triples of
an IfcDoor object. IFC-to-RDF is a set of reusable Java component that allows parsing IFC
files and converts them into RDF graphs. Our implementation deploys modified version of
IFCto-RDF conversion plug-in provided by
Second thread executes geometric pre-processor to extract geometric related data from an IFC model. It employs Geometry Render Engine to extract geometric information and stores them as RDF triples in the semantic repository. Figure 2 illustrates the output triples corresponding to bounding box values of an IfcDoor object. Mainly there are two geometry render engine plugins available with the BIM Server named IFCOPENSHELL and IFC Engine DLL. These are helpful to extract geometry data about the IFC objects. The outputs of this preprocessor are the RDF triples which are formed from the extracted geometry data of relevant IFC objects. These two pre-processors are executed in parallel to gain time. The advantage of their parallel execution is that none of the threads wait for each other, their functionality is different so they can efficiently utilize the server processor to achieve their desired tasks. These threads propagate their results to the next thread. Once all RDF triples (i.e., Filtered RDF file of an IFC model and RDF triples corresponding to Geometry data) are generated by first and second threads, third thread gets and loads these RDF triples into the triple store for the fast querying, searching, and analyzing of RDF triples.
Third Thread executes to build the semantic repository (i.e., triplestore) with the output of previously discussed two pre-processors. It waits till it is triggered by the outputs of Converter thread and Geometry Extractor thread. It will not start until both the threads finish their execution completely and generate RDF triples. It uploads all the RDF triples to the triplestore. All types of inference and reasoning mechanisms for the semantic verification are applied over this semantic RDF repository to meet the requirements of compliance checking, and in addition to discover additional information that is not explicitly stated in the initial data of the IFC model. We have integrated both forward chaining and backward chaining mechanisms (where appropriate) to build our semantic repository. Several newer concepts, SPARQL rules (statements and materialization) are applied to enrich the underlying semantic repository as per the demand of verification rules. Use of forward chaining mechanisms support the dynamic semantic verification for the future checks. The following are its sub-components. TripleStore – Stardog. Although IFC is an open standard; its complex nature makes information retrieval difficult from an IFC model when the size of IFC model grows. Therefore, we have used Stardog as a triplestore to build our semantic model so that querying semantic model is faster and gives a good run-time. When the application starts, an end-user provides an IFC model and the set of SPARQL queries which are the verification rules for checking code compliance of desired IFC model. As a result, our system converts an IFC file into filtered RDF model. It loads that converted-filtered IFC equivalent RDF into stardog. After RDF triples concerning geometry are added to capture geometrical information in the triplestore. Then the semantic model is enriched with IfcOWL basic vocabulary, i.e., sub-graph of IFC ontology. Then, it adds SPARQL rules into the triplestore. Finally, it executes our project specific forward chaining SPARQL queries which creates high level vocabulary and builds further RDF graphs over the existing triplets.
IfcOWL ontology sub-graph. As the standard IfcOWL ontology (Terkaj & Pauwels, 2014) has a very large set of IFC elements, therefore, we deal with the sub-graph to achieve better processing and querying performance.
SPARQL Rules – Statements. We have created a large set of SPARQL rules, i.e., statements. In fact, these statements are shortcuts overs the long chain of triplets to enable simplicity. For instance, we created ‘intersects’ shortcut over the RDF triplets corresponding to bounded box values of IFC elements (see Figure 3). These statements promote readability, understandability and enable simplicity when creating SPARQL rules and queries. Otherwise the chain of triplets make things complex and ambiguous. SPARQL Queries - Materialization. During the analysis of rules specification, we come across various types of vocabulary (introduced by regulatory texts) during building code compliance application. This vocabulary is composed of high level concepts present in business rules and regulation texts which are familiar by the stakeholders of BIM. There are two methods to build such vocabulary of newer high-level concepts, i.e.; via forwarding chaining and/or backward chaining. Based on the SPARQL rules, we have built SPARQL queries to introduce high level concepts based on the primary IFC vocabulary by using both forward and backward chaining where applicable. Figure 3 shows high level concepts ‘intersects’ in our case study of building French code compliance via forward chaining. Backward chaining consists of ontology statements that align IFC concepts with regulatory concepts, whereas forward chaining consists of insert statements that create supplementary triplets. Forward chaining is a good at an implementation stage to save memory and CPU resources. From the machine point of view, backward chaining is processed each time a semantic query is submitted whereas forward chaining is executed each time the data changes. At this stage, this choice is a compromise between effective queries (forward chaining is more appropriate for complex and numerous queries) and model update frequency (backward chaining is more appropriate when data changes frequently). We can even say that it is a compromise between the amount of triplet (considering triplet generated by forward chaining statements) and the ontology complexity. Therefore, we have mixed both approaches backward and forward chaining to provide the optimal setting that minimizes response time and maximizes ontology consistence. With the help of these techniques, we have simplified several IFC patterns such as classifications, predefined types, properties, geometry, topology, etc.
Fourth Thread executes rule evaluator also called compliance checker as it performs the fundamental task of evaluating building model against building codes. It waits till it is triggered by the outputs of third thread that builds semantic repository to fast access triples to fetch data and validate IFC models. It performs SPARQL queries over the semantic repository for the verification and code compliance of an IFC model. An end-user may apply SPARQL ASK and DESCRIBE queries to retrieve relevant information regarding the verification rules. Instead of using IfcDoc tool where there is no intermediate state and no explanation for the reason of noncompliance, we use SPARQL DESCRIBE Queries. The SPARQL DESCRIBE query does not actually return resources matched by the graph pattern of the query, but an RDF graph that "describes" those resources. It is up to the SPARQL query service to choose what triples are included to describe a resource. Therefore, SPARQL queries serve best by concatenating desired triplets for building verification rules to check the code compliance. Figure 5 shows an example of SPARQL query to detect whether an ‘Alarm’ is installed at some space in the building. This query is based on semantic rules ifcowl:in and ifcowl:inStorey which are also shown below the query. Once, it finds an IFC model which is not instatlled with an Alarm (in this example) or non-compliant objects in the IFC model (in other cases), it presents them to the end-user as inconsistent elements in the building model. With the knowledge graph over RDF triples, we have the freedom of extending our semantic IFC model, creation of newer vocabulary and formation of newer rules, concatenation of RDF triples to build rules with condition and constraints over IFC data, dynamic reasoning over the RDF triples based on the initial data of IFC model, etc.
The following sub-sections elaborate implementation and testing details of SBIM-Reasoner.
We have developed SBIM-Reasoner as a semantic service inside a KROQI platform. As it is developed especially for the French building code compliance, therefore our web interface is also in French targeting French community. When the application starts, an end-user has to configure IFC input model by clicking under the synchronization button on the very first tab ‘Maquette’. Then an end-user selects the set of rules to be verified on this input model by selecting/browsing their set of rules on the second tab ‘Protocoles’. Then our web service starts by calling semantic reasoner which computes the set of rules and redirects to the result page ‘Résultats’. Each of the rule is highlighted as green or red color depending on its status of compliance (see Figure 5a). When SBIM-Reasoner detects non-compliant objects (in case of red status), an end-user can further analyze them by clicking on the corresponding row. It displays the list of IFC non-compliant objects containing Name, GUID and Type of each IFC object (see Figure 5b). One can also export PDF and BCF files to analyze their results in detail.
We deployed SBIM-Reasoner service on a cluster kubernetes of 3 nodes (1 node = 1 VM), where each node has 4 vCPUs, 26 GB memory and type of Intel(R) Xeon(R) CPU @ 2.30GHz. We choose several IFC models (see Table 1.) from the online repository to test our Semantic BIM Reasoner such as; Chanteloup (17 Mb), AC9R1-Haus (4 Mb), BIM-EM (2 Mb), Candidat (29 Mb), HITOS (63 Mb), and LcD (32 Mb), etc. 205,631 2,138 132,115 142,668 132,845 13,973 100,230 21,549 86,545 These IFC models vary in size, number of IFC objects, free spaces, etc. We have also used four IFC models developed at our CSTB enterprise named Bat_CSTB (14.9 MB), HAixFlowCtrl (13.1 MB), Maquette Test Checker (11.2 MB) and Liberty (12.2 Mb). Tables 1 shows the size of these IFC models, the number of triples in the RDF equivalent to the original IFC model and the filtered model by IFC2RDF pre-processor. We took many different analysis parameters such as number of RDF triples in the RDF (turtle file) equivalent to IFC model, number of RDF triples in the semantic model (filtered turtle file) in the triple-store, estimated time taken by the conversion pre-processor and geometric pre-processor, etc. We have measured time taken by different preprocessors that produce desired output in Table 2. Our first version implementation is without multi-threading where pre-processors run sequentially. Our system gets input of an IFC model along with the rule set to be verified on the building model. It invokes conversion pre-processor, and loads the equivalent RDF triples into triple store. Then it runs the geometric pre-processor and gets the bounding box values (i.e., min/max values X, Y and Z coordinates) and updates the triple store with the geometric RDF triples. Finally Rule Evaluator runs the SPARQL queries to verify the compliance of building codes. Later in our implementation which is the contribution of this paper, we adopted multi-threaded approach where geometric and conversion pre-processors run parallel to produce output RDF triples. In our test experiment, there are IFC models of various sizes and structures. An IFC model named HITOS is the largest building model which has 62.5 Mb size with 205,631 number of RDF triples and BIM_EM is the smallest building model which has 1.9 Mb size with only 2,138 number of RDF triples. When we see the time graph, we observe that SBIMReasoner took less than a minute by both the pre-processors to achieve their objectives when the size of IFC model is under 15 MB. But when the size of IFC model is 62 MB (in case of huge IFC model Hitos) then it took almost 3.4 minutes to convert and filter, and more than 5 minutes to extract geometry data. Here, we also mention that although pre-processors took time to build semantic model at the first time, but querying for the verification of IFC models are processed fast and a good run-time is achieved. On the other hand on traditional IFC model, it takes much time to verify each of the individual rule. In addition, we are not able to execute all types of rules as per our desire due to narrow scope of IFC tools available online. This is only with the semantic model that we are flexible enough to fetch any triplets and build rules according to our will for the verification of IFC models. We revealed encouraging results via 40 9 7 27 18 31 11 8 14 12 10 8 7 10 10 9.5 9 8 9 9 563 43 40 150 100 241 87 67 84 82 358 33 30 102 69 144 60 48 62 59 several tests from the initial version of SBIM-Reasoner. The results of SBIM-Reasoner are checked manually to access the correctness of SBIM-Reasoner for each of the building models and they were 100% correct. On the basis of this analysis, we conclude that semantic model serves best for the verification of IFC models. We conclude that for such modules where execution can be done separately, multi-threading can benefit and gain time. It is highly visible when an IFC model is large (in the case of HITOS IFC model), parallel processing and CPU utilization reveals these pre-processors to execute simultaneously resulting the whole process take lesser time to achieve the whole functionality.
In the context of BIM when the question about the evaluation of an IFC model appears, the implementation of compliance checking of IFC models is vital to address. It is necessary to detection inconsistent and non-compliant IFC objects to ensure quality and reliability of an IFC model in the entire life-cycle of BIM. Compliance checking is an exhaustive process which cannot be done manually, in addition requires revolutionized advanced technology to process due to complex inherent nature of an IFC model itself. There are many techniques for the automatic verification of IFC models, but, still there are many open challenges. In this paper, we evaluated the idea to formulize building code rule as a semantic SPARQL query and then execute it on the building model to check the possibility of non-compliant elements in the building model. We have built a research prototype named SBIM-Reasoner which employs semantic approach for the building code conformance checking. We have tested and concluded that our approach based on semantic queries and rules can be easily extended, configured and deployed for the dynamic and changing BIM environment having broad spectrum of functionalities for the conformance checking of IFC models. We have also analyzed how multithreaded approach can benefit our solution by comparing run-time of our two implementations with and without threading. We demonstrated several test models on SBIM-Reasoner and presented its efficiency and efficacy with empirical results. We conclude that the semantic model based on the semantic web technology is a good compromise between development efforts and opportunities. The graphical representation of RDF allows rules to be more intuitive and more efficient to reason and execute. Concatenation of triplets allows flexibility of making wide range of verification rules with condition and constraints at ease. SPARQL has a global scope with larger visibility of querying with the built-in functions and support of intermediate calculations for the validation of IFC models.On the basis of several analysis parameters, we have shown encouraging results by several tests on the SBIM-Reasoner. We have also found that multi-threading based approach served best and provided faster computation for the conformance checking of IFC models. SPARQL Query Language for RDF (2013), http://www.w3.org/TR/rdf-sparql-query/ [last access: jan 2019] Thein, V. (2011). Industry Foundation Classes (IFC), “BIM Interoperability through a Vendor-Independent File Format,” A Bentley White Paper, September’11.
Terkaj, W., and Pauwels, P. (2014). “IfcOWL ontology file http://linkedbuildingdata.net/resources/IFC4_ADD1.owl [last access: jan 2019] for
IFC4”.
Available
Zhang, C., Beetz, J. & Weise, M. (2014). “Model view checking: automated validation for IFC building models”. In Mahdavi, ed. eWork and eBusiness in Architecture, Engineering and Construction: ECPPM’14.