Automatic rule checking is becoming more and more important in the build environment. It has been identified as potentially providing significant value to the AEC industry from both regulatory and industry perspectives (Solihin et al, 2015). Regarding construction-specific applications, researchers have looked into regulation compliance checking as well. The most commonly known application of automated regulation compliance checking, is the ePlanCheck system in Singapore. Only 70 to 80% of the regulatory knowledge can be explicitly formalized. Issue: conversion from a natural language regulation text to a formal representation.
There is theoretically an infinite number of rules that can be defined, and therefore it is critical to structure the rules to make the task of rule checking manageable. Over the years, BIM tools and the opportunities they offer have become more complex. Relying on just visual inspection is no longer viable to ensure BIM models are of good quality and conform to the projects requirements. With the successful implementation of basic rule checking, experts are able to focus on higher ends of the value chain which are difficult to define and automate. Currently, automated rule checking systems serve as a decision support system where user input is required. The final aim of rule checking systems should be a fully automatic system that lets experts focus aspects that are more important, such as environmental impact, sustainability and safety. Solihin and Eastman (2015) have categorised the following automated rule checking categories:
– Well-formedness of a building model based on a set of standards or prior agreed set of conditions for the IFC.
– Building regulatory code checking. Determines whether the model aligns with building codes or regulations.
– Specific client requirements such as hospitals or other public affairs.
– Contractor and constructability requirements. This involves temporary pre-construction requirements.
– Warrantee approvals. This is a post-construction requirement check to see if the warrantee or cost of maintain is affected during construction.
– BIM data completeness for handover to the facilities management. At the end of each contract phase the BIM model will be checked for completeness.
Furthermore, Solihin and Eastman (2015) classified the rules according the complexity of the rules processing. They have distinguished four different kinds of classes:
Class 1: Rules that check explicit attributes and entity references that exist inside the BIM dataset.
Class 2: Rules that are based on simple or small set of derived data.
Class 3: Rules that require extensions to the data structure which encapsulate higher levels of building data often involving geometry operations.
Class 4: Rules that focus on building compliance rather than rule checking.
Limitations of an IFC file:
‘As a typical object data model, IFC structures data mainly for the purpose of data creation and exchange rather than for the understanding of the knowledge domain, and information is usually represented using relatively complex structures. All these issues have brought about difficulties regarding data query and management on IFC instance data.’ (Zhang and Beetz, 2017 (in paper)). While on the other hand, a large amount of information is implicitly available in an IFC file.
Thesis| L.J.P. Gerritsen | Page | 24
4. Model
The rule checker is created based on the following steps. First, the current available rule checking systems will be discussed. Then, the starting point of the rule checker for this thesis will be explained. The target data source, the method of creating rules, which rules will be checked and why. A visualisation of the results is presented in the next chapter.
4.1. Available rule checking systems
Presently, there are several applications attempting to query and analyse IFC data. Examples are Solibri model checker and Jotne EDModelChecker. These programs differ in capacity, flexibility, reporting and how results are visualised. The most common checking systems will be discussed below. Unfortunately, the semantics of query functions in these proprietary systems are not transparent and the usage of them is limited by provided interfaced for users.
BimQL, developed by Mazairac and Beetz (2013), was the first implemented and open source domain specific query language for querying IFC data. The tool isn’t further developed. Furthermore, there are a few domain specific query languages, such as The Building Environment Rule and Analysis (BERA) Language. BERA is a domain-specific language dedicated to evaluate building circulation and spatial programs (Mazairac et al, 2013).
Solibri model checker (SMC)
SMC is a JAVA-based platform application that reads an IFC model and maps it to an internal structure facilitating access and processing. It offers the user a variety of features such as clash detection, deficiency detection, the matching of elements, managing design versions and Bim data mining. SMC imports IFC, compressed IFC and DWG formats and is compatible with ArchiCAD, Revit and other major commercial software. Rules can be parametrically varied through table set control parameters (Nawari, 2012). New rules can be added using the SMC Java programming interface. However, the API interface is not publically available, restricting the rules to be checked to those supplied by Solibri (Eastman, Lee, Jeong, 2009).
Jotne EDModelChecker (EDM)
Jotne EDModelChecker supports the open development of rule checking using the EXPRESS language. This is convenient, since IFC is written in EXPRESS as well. Furthermore, EDM uses EXPRESS-X to develop new model views, which is the foundation for extensive queries and reports (EDM, 2009).
Tekla BIMsight
Tekla BIMsight is developed by Tekla, a company that provides software for customers in construction, infrastructure and energy industries. Tekla BIMsight main usage consists of one main platform for collaboration, combining models from different disciplines and automated clash detection. Furthermore, valuable information can be shared instantly during construction.
4.2. Target data source
The IFC data format is currently widely supported by the market leading BIM software vendors and is seen as the de facto standard for interoperability. Therefore, the automated compliance checker will be based on the IFC file format. This leads directly to one of the main problems of the IFC file format. The data structure of IFC files collides with the requirements of the rule checking environment (Pauwels & Deursen, 2012). By using Web of Data Technologies (Semantic Web), this problem could be solved. Semantic interoperability makes model data sharable and understandable across multiple design disciplines provides integration at the highest level (Yang & Zhang, 2006). Törmä (2013) Converted BIM models saved as IFC files into representations used in the domain Web of Data (Linked Data). Thereby, he enabled the possibility to query the data. Differences between IFC and Linked Data are displayed in table 1.
Thesis| L.J.P. Gerritsen | Page | 25
Table 1: Differences IFC format and Linked Data format
IFC
Linked Data
Identity
GUID
URI
Schema
EXPRESS
OWL
Data
Part21
RDF
Access
HTTP
Queries
SPARQL
Looking at the data source, it can be seen that the data source is different for IFC and Linked Data. A major advantage of the RDF data source, is that the data can be queried with SPARQL. This is the main reason the automated rule checker will be based on the Linked Data format. This means the IFC data model needs to be converted to RDF data set. Pauwels and Terkaj (2016), have created a tool that converts the IFC data format into RDF. This tool will be used the initial data source (IFC) into the RDF data format. The RDF data format is more accessible and editable, compared to the IFC data format
Vocabularies
The target source for developing extended functions is the IFC file format. IFC is developed by BuildingSMART International and is a much used format for the exchange of building models (BuildingSMART, 2015). Collaboration is made possible thanks to the IFC file format. IFC-based building model information can roughly be grouped into domain semantics and geometric data. Domain semantics consist of object types, relationships and properties. Geometric data, which is a low-level technical description captured by geometry object associated with IfcProduct instances. The IfcProduct is an abstract representation of any object that relates to a geometric or spatial context (BuildingSmart, 2015). For this thesis, I choose to work with blank IFC files, not edited by a company’s own vocabulary and parameters, so ensure this tool can be used with most IFC models. The mapping of native software towards IFC, with the correct fire safety parameters, is still difficult in practice.
Starting point
Zhang and Beetz (in paper) his BIMSPARQL tool forms the basis on which this tool is developed. Many rules have already been defined in his research. Therefore, instead of creating a similar Java program, this tool is built within the BIMSPARQL tool from Zhang and Beetz (in paper).
4.3. Rules
Based on the literature study and the qualitative research, the rules that will be checked with the rule checker will be described here. T
4.3.1. Fire resistance rating
The Fire resistance rating of building elements must be included regarding fire safety. For each function group (see paragraph 2.4.2), a building element is required to have a minimum fire resistance rating. For example, the structural elements in first three stories from a six story apartment complex need to have a fire resistance rating of at least 60 minutes. The fire resistance rating should be higher for apartment complexes for elderly. Their response time is less than the response time of younger people, see paragraph 2.1.4. Fire resistance rating can be found in Pset_CoveringCommon. The fire resistance rating is measured in minutes in intervals of 30, 60 and 90. Each interval has been added to the checker. Below an example is presented, regarding walls with a fire rating of 30 minutes. The complete code can be found in Appendix B.