BIM quality control based on requirement linked data

Definition of a requirement

Regarding requirements, firstly, it is wise to understand the exact meaning of the word. According to etymonline ⁷ the word “requirement” originates from the word “require,” which comes from Old French “requerre” meaning seek, procure, beg, ask, demand which comes from Latin “requirere.” The “re” means repeatedly and “quirere” means query. This is interesting, because it seems from the very early times when they used the word, it was a query or demand that occurred multiple times, which means from the beginning it is a great terrain for automation—of course the technology for such is just given in the latest times.

According to Cambridge Dictionary, ⁸ it means, “something that you must do, or something you need.” In a design context Wikipedia, says the following: “. . .a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design….” ⁹

Requirements may be categorized in three types: according to the subject of the requirement, according to the data format type of the requirement, and according to the origin of the requirement. The subject of the requirement can refer to the building as a product or to the process of the design or construction. This paper only deals with requirements applying on the building as a product. Requirements targeting processes are out of our scope, whereas it is also a necessary part of a BIM workflow. If the future physical building is taken as a product, the requirements can be interpreted on several levels. It can refer to the building as a whole, it can refer to a concrete structure or element of the building, it can refer to a structural connection or to a material. Every discipline has their own more or less different domain with their different subjects of requirements. It is an important task to consider all of these, if a universal logical model for requirements is desired. According to the description type of the requirement data, it can vary on a large scale. It can be plain text, a concrete value, table of values, calculation formulas, assessment systems, maps, or any combination of the previously listed. In the next paragraph, examples which occur the most in architecture are going to be listed. According to the origin of a requirement, it can be anyone from the direct or indirect project participants: clients, regulators, designers and discipline designers, constructors, facility managers, etc. Distinguishing the origin of requirements is favorable because their frequency of data delivery, their data format of delivery, their data reliability, and their data updating habits can differ, which all has an impact on the quality checking process.

In the software industry the following characteristics are generally acknowledged regarding good requirements: unitary, complete, consistent, atomic, traceable, current, unambiguous, prioritized, verifiable. ¹⁰ The AEC industry is a sector with a lot of traditions, hence it does not entirely fit the characteristics of the above listed, whereas it should be a goal to accomplish these characteristics in the future, which needs effort from all project stakeholders including authorities and clients as well.

Data analysis on the main type of requirements used in architecture

Originating from the client, the brief is the document that sets the project goals, constraints, requirements, and initiates the building project. As Koutamanis ⁴ brings up, a brief is actually an information system, a complex database that has many tables of information that are connected to each other. These tables basically connect requirements to elements and vice versa. Most of the following examples can be part of a brief, while some of them are engaged by only the designers.

Building or space program: Narrowly speaking, it is a list of all the required spaces with area requirements attached to it. There is not a standard format for it. Its data format is a table, which depending on the creator of the brief can contain additional requirements and constraints, for example: “Space type, Room name, Area, Height, Occupants, Proximity, Design comment.”

Functional requirements: In the functional requirements the client gives information of the purpose of the given premise. It articulates who is going to use the room, how are they going to use it, what special activities they are going to do. Its data format is usually text, for example: “The office room should suit the needs of four architects, who work 8 h a day behind high quality workstations, with screens.”

Financial requirements: Financial requirements can be interpreted on project level, building level, or element level. The data format can be text, table, or value. For example, “the pay-off rate of the project has to be 4% in 10 years” or “the total cost of the building cannot exceed 100 million euros,” or “the money spent on groundwork cannot exceed the 15% of the entire building.”

Aesthetical requirements: The aesthetical requirements regarding for instance, style, shape, or colors are subjective requirements. Therefore, the data format is always text. For examples: “the building should be futuristic,” “the building should have playful colors,” “the shape of the building should suggest a sailing ship.”

Building performance requirements: There can be a great deal of discipline requirements concerning building performance. These requirements may origin from regulations or from professional standards, rules of thumbs, and additional needs. The subjects of the requirements can also vary from the whole building, through integrated structures, to elements or materials of the building. The data format can be text, table, value, or calculation method. For example: “according to the Hungarian 7/2006 (V.24.) TNM Energy Code of Hungary the U-value of the roof has to be min. 0.17 W/m²K,” “according to the Hungarian 54/2014 (XII.5.) BM regulation about the National Fire Protection, the escape doors have to have a 60-min fire protection value.”

Building code and regulations: Building codes are specifying the degree of freedom concerning the geometry of the building, while local regulation maps are separating functional zones in the city, showing what functions are restricted in the given area and what types are free to build. The data format is usually text and maps. For examples: Hungarian Country-wide Urban and Building Requirements (OTEK), Local Urban Regulations.

Complete discipline assessment: There are disciplines which give a complete methodology to evaluate the building. For instance, LEED or BREEAM certification lines up several complex requirements from environmental aspects against the building. There are several subtopics where the building is being assessed and the sum result is a point, which in a certification range means a category. For example: basic, silver, gold, or platinum category. Accordingly, the data format of such a requirement is a methodology description in text format and the process has several calculations and data verification steps, sometimes supported by digital tools. ¹¹

Thus, these are the types of requirements that need to be checked during the QC process, in an ideal world, in a fully automated manner. There are many terms used in literature for this action: compliance checking, code compliance checking, clash detection, rule checking, model checking, validation checking, BIM-checking, quality checking, and many more. ¹² In this paper, “BIM compliance checking” and “BIM quality checking” are used in synonyms, for naming the BIM based automated quality checking process.

The four steps of BIM compliance checking

A compliance checking process has four major steps ¹³ (Figure 1). The first is “rule interpretation.” There are several approaches to translate and formalize the requirements written in natural languages for a compliance checking system: software approach (i.e. Solibri, Navisworks), object-based approach (i.e. CORENET e-PlanCheck), logical approach (i.e. if-then validation, decision table methodology), ontological approach (i.e. RASE, SBVR methodologies). The second step is the “building model preparation.” A BIM model must be built in a way that it enables quality checking. It is important that the structure of the model and the information richness needs to conform with the given quality checking method. The third is “rule execution” or in other words, requirement conflict detection. This is the process when an algorithm compares the designed values to the requirements and creates a pass or fail tag according to the result. The fourth is “reporting” the result, when the results of the previous step are communicated to someone. This can mean a 3D visualization on the screen or a table with the conflicts each line. The purpose of this stage is to give a solid ground for designers to solve these issues. Such a report helps humans understand, follow, and solve these problems effectively.

OPEN IN VIEWER

Figure 1.

The four major steps of the compliance checking process based on Ismail et al. ¹³ Icons by flaticon. ¹⁴

In this article the rule interpretation and the building model preparation steps are not going to be further discussed. It is assumed that requirements can be formalized to a certain extent. During our literature review several articles, that confirm this assumption, have been found. According to Eastman and Solihin, ¹⁵ as experienced in the FORNEX e-Plancheck project, the interpretation step can take as much as 30% of the total time of the whole process. The effort spent on rule interpretation depends mostly on the complexity of the rule. There are examples for compliance checking where the interpretation worked in different domains well: fire safety, acoustics, sustainability, construction, etc. Koutamanis ⁴ analyzed 10 building briefs and found that only 0%–22% of the requirements were not supported in a BIM environment for QC theoretically. In another case, Bouzidi et al. ¹⁶ formalized French Technical Guides to SPARQL language, where they were unable to implement 70% of the rules. Apparently, the solutions and the effectiveness of the interpretation methods vary on a great scale, but it works and automated compliance checking to any extent saves time for the designers and saves money for the client.

The four types of BIM compliance checking

According to Hjelseth, there are four types of BIM Model Checking ¹² (Figure 2). The first is validation checking or in other words conflict detection. Clash detection is the most common example of validation checking, while code checking is an example of a popular type of checking, but with limited implementation. The validation checking can be based on multiple sources like codes, standards, contracts, best practice, or by other defined requirements. The second is model content checking, which aims to control the information richness of the model. According to an etalon list it states if all the necessary information is in the model or if there is extra unnecessary information which slows down the process. The third is smart object checking. This is not a posterior checking but a real time adaptive one. A parameter of a given object can be linked to another object’s parameter so when it changes, it automatically refreshes the connected parameter and adapts to the new state. According to our interpretation this type of checking could be possibly a subdivision of the validation checking type. The fourth is design option checking. This means that the BIM model is being confronted to a complex knowledge base and alternative design versions are given according to the conclusions. These types of solutions are at a very immature level in the AEC industry.

OPEN IN VIEWER

Figure 2.

The four types of BIM compliance checking according to Hjelseth. ¹² Icons by flaticon. ¹⁴

Present solutions and tools

The first group of tools that enable automated compliance checking to a certain extent are the briefing, specification, and project database software tools. A benchmark ¹⁷ has been conducted in late 2019 with briefing software products^18–20 (MasterSpec, Bsdspeclink, dRofus) used in practice. After learning about the capabilities of the software products listed, it seems the market has changed since 2017 and the software is more developed, but the statement is still valid from Koutamanis: “Existing tools are less than generous with their connections to BIM. Most preserve their standalone character, merely allowing content to be imported or linked to BIM. Their information generally remains locked in databases hidden in proprietary software, often replicating data that exist in a model and impeding connections between different kinds of information.” ⁴

The second group of such solutions are executed by CAAD and BIM programs (e.g. Revit, ²¹ Archicad ²² ) with extended plugins, scripting, or in combination with Excel. Most of the case studies reported about using Revit plugins for a given discipline requirement checking, for example, for fire protection rule checking.^23,24 There are also scripts that generate a TRUE or FALSE value in the BIM software if a certain parameter of an object complies with a requirement value. The simpler version of this solution is when the objects with their parameters are exported to a table and the comparison resulting TRUE or FALSE value is generated in Excel. These solutions are working only with those discipline requirements where the nature of the rules is mostly simple data validation and the rule diversity is low.

The third group of programs are the model checkers. The ones that are mostly used in practice are from the big software vendors^25,26 (Solibri, Navisworks), but there are also emerging cloud based solutions.^27–31 These solutions provide automated analysis and checking regarding design issues, detecting design deficiencies, and checking the model against rulesets, for example, accessibility, fire protection, etc. Mostly they implement hard-coded functions, therefore the end-user cannot find out how the rules exactly work. It is argued that adding new rules is a difficult task as it can only be custom made by the software developers. ³²

In the fourth group, there are research projects with different experimental methods for compliance checking. Most of them are based on the open standard file formats and data schemes governed by building SMART, ³³ such as IFC, BCF, and mvdXML. During our scientific review only one freely accessible workflow, called IFCdoc-mvdChecker workflow ³⁴ has been found, with open source or free software and usable documentation. It is going to be introduced in detail in the next section, but the conclusion was that there are two major issues with it. One comes from the limitation of the IFC: limited expression range, difficulties in partitioning the information, multiple description possibilities for the same information, ³⁵ rigorous flexibility, not tailored for query, and analysis tasks. ³⁶ The other is the User Interface (UI), which is not designer friendly.

As a matter of experimental methods, there are two main directions: using Structured Query Language (SQL)^13,37–39 or Semantic Query Languages. ⁴⁰ There are advances in both directions, but it looks like the semantic approach is the more forward-looking one. The use of Shapes Constraint Language (SHACL) is suggested by the authors and other researchers as well.^36,41 An example of using SHACL for compliance checking of a BIM database will be introduced later.

Suggested principles of a BIM-based compliance checking

On Table 1, eight principles are proposed, based on the literature review and market research discussed above and modern data management theory regarding data openness and interoperability, ⁴² that should be satisfied by a state-of-the-art BIM compliance checking system.

OPEN IN VIEWER

Table 1.

Suggested principles of a BIM-based compliance checking.

I.	Quality Control is expected to be software independent, interoperable, and open source.
II.	The method of requirement input should be automatized.
III.	Possibility for conflict detection in requirement fulfillment.
IV.	The result of the conflict detection should be visualizable in multiple ways.
V.	The quality checking method should exceed the limitations of the IFC data structure.
VI.	The requirements should support data linking and data interoperability.
VII.	Contiguous data flow from the source of the requirements to the quality checking agent.
VIII.	Requirement data governance should be distributed at the responsible agents.

Fulfillment of suggested principles on existing solutions

The main goal was to look at the big picture of the above discussed solution repertoire in a comparable manner to see the fulfillment of our suggested principles. Therefore, a comparative analysis has been made on Table 2. Only the results of each solution category are listed, where the software products and services are summed that were mentioned under “Present Solutions and Tools.” Three types of markers were used: yes, no, and partly. Yes, means all of the solutions in that category is according to the given principle, while no means the opposite. Partly means there are solutions that more or less satisfy the given principle.

OPEN IN VIEWER

Table 2.

Comparative analysis on available quality checking solutions by category.

	I.	II.	III.	IV.	V.	VI.	VII.	VIII.
	Software independent, open source	Automatized requirement input	Conflict detection	Multiple visualization methods	Exceed IFC limitation	Support data linking and interoperability	Contiguous data flow from source to agent	Distributed requirement governance
Briefing softwares18–20	No	Yes	Partly	Partly	Yes	No	Partly	No
CAAD and BIM software solutions21,22	Partly	No	Partly	Yes	Yes	No	No	No
Model Checkers25–31	No	No	Yes	Yes	Partly	No	Partly	No
IFC doc, mvdChecker Workflow 34	Yes	No	Yes	Partly	No	No	No	No
Experimental research projects13,37–39	Yes	Partly	Yes	Partly	Yes	Yes	Partly	No
Building SMART file formats 33	Yes	Partly	Yes	Partly	No	No	No	No

Firstly, there is no solution which satisfies all principles. Secondly, it is apparent that the last three are the main bottlenecks, meaning there is not yet a widely recognized solution based on Linked Data. Also automatized parameter input is only figured out in the minor of the solutions. On the other hand, conflict detection is doable in most cases and there are open-source solutions which are only in the seed phase but started to evolve in a good direction. The same is valid for the visualization methods. There are some promising dashboards and visualization methods for the QC results, but designer friendly and efficient solutions are still awaiting.

To sum up, there is no BIM based QC solution that satisfies our principles and is accessible for offices in a usable and affordable way. Although the quality of basic geometrical and attribute information export has improved and some BIM products started Application Programming Interface (API) data exchange services, there is still no standard for requirement data exchange which could allow the integration of the already existing BIM tools. There is state-of-the-art research tackling this topic and testing prototypes but there is a great need for BuildingSMART, as the leading party in open file formats concerning the AEC industry, to make advancements regarding this topic. In the following, the currently available state-of-the-art QC workflow has been investigated, where the above-mentioned solutions are used.

State-of-the-art open BIM based quality control

The state-of-the-art open BIM QC workflow is shown on Figure 3 based on the literature review and the market research discussed earlier. Only those QC solutions have been put on the workflow diagram, that are thought to be of a consensus in the literature and which have usable and accessible solution for a given function. There are two types of blocks. One is the source of requirements, who are the responsible agents, namely the client, the authorities, and the designers—shown by icons—and the other is the QC solution block. In the following, these blocks are explained one by one.

OPEN IN VIEWER

Figure 3.

State-of-the-art open BIM based quality control.

Suggested open BIM based quality control ecosystem

Most research regarding this topic focuses only on a few aspects of the BIM QC workflow, for example, on regulation to rule conversion methods, analyzing and testing new technologies, or creating new pieces of software. Even if their research scope involves the context, usually their solution deals with only a certain discipline requirement type of the QC problem. For example, fire safety, with only the related software and user environment. Therefore, from the industry point of view, these are partial successes, but from a universal BIM QC point of view, these approaches are not wide enough. Hence the concept “BIM Quality Control Ecosystem” has been introduced, which deals with the QC solutions, the involved parties, and their relation to the whole process at the same time.

An ecosystem is suggested on Figure 4, that corresponds to our previously stated principles. As a result, the QC process will be of better quality, with less administrative workload on the project participants, enabling BIM design methods to become cheaper and more widespread.

OPEN IN VIEWER

Figure 4.

Suggested open BIM based quality control ecosystem.

In accordance with the above, our ecosystem is a modular and open system, where BIM functions are separate entities. This way any module is replaceable and the software in use can be freely chosen.

Every party who establishes requirements are responsible for them and they must govern them throughout the project. Moreover, there is a Linked Data connection between these parties’ requirements all the way to the quality checking tool. This means a lot of administrative redundancies and extra human-to-human communication can be saved, while the chance of making mistakes is reduced.

The ecosystem relies on three databases: the first is the BMC server, where all the quality checking rules from all different sources are collected. The second database is the BIM server where the design models are stored. The third one is the BCF server where the issues concerning the design process are stored. One can input data into these databases and can query these databases with a suitable software tool. While all these databases should avoid redundancy, should be based on linked data and should track changes, this paper only focuses on the BMC server and the requirement information in our conceptual example. Regarding the other two databases, it is desirable to build upon tools which are already used and can be adapted to the ecosystem while corresponding to our principles. That is why the BIM Server ⁵² and the BCF Server ⁵⁵ have been applied. It was also desirable to enable Transparent Design, ⁵⁶ which means any requirement conflicts can be traced back to their sources at any given point of the design process.

Proposed data model for requirements

Our suggestion is formalized as an ontology, since interoperability and self-description are core features of Linked Data, to be utilized here. The usage of Linked Data is growing significantly year by year. In the EU, Core vocabularies are promoted for describing Persons, Businesses, Locations, Criteria, etc. ⁶¹ Further ontologies or RDF schemas are widely used for metadata provisioning (Dublin Core ⁶² ), describing persons (FOAF ⁴⁹ ), metrics and measurements (QUDT ⁵⁰ ), etc. In fact, BIM also follows these principles, though IFC is not defined primarily in RDF. For example, the BIM Ontology ⁶³ helps to structure semantically the terminology of buildings.

In 2018, the UN World Data Forum also voted for the linked-data approach in its guide for data governance. ⁶⁴ Hence, the solution suggested here is the BIMReq ontology ⁶⁵ (Figure 5), which enables rich semantic description of requirements, thus leverages intelligent management, reasoning, and visual evaluation of building requirements. BIMReq offers descriptions for the following concepts: regulations, requirements, and evaluations.

OPEN IN VIEWER

Figure 5.

Key elements of the BIMReq ontology.

Regulations are described primarily with the metadata necessary for identification using Dublin Core terms. In this way the date, creator, name, and identifier of the regulations can be provided by the regulator together with the link to the full regulatory text. Furthermore, subject classifications may be given by discipline type and regulated object type. Optionally, a full SHACL ⁶⁶ expression may be attached translating regulation text into compliance checking rules. Ideally, the Regulation Linked Data would be maintained and made accessible by the regulator.

The next key concept is requirement, which can be grouped into requirement sets and can be bound to construction projects and IFC models. Requirements may be raised by the client or a designer but may also be derived from regulations. In the latter case the requirement connects the regulation to selected parts of the IFC model and may also concretize the expected measurements. Requirements should also contain descriptive metadata, minimally the creator, creation date, and short description. Subject categories can help filtering requirements by object type, object location, or discipline type.

There are several possibilities for automated compliance checking, depending on the tools and formats used in the project. In case of IFC XML, Xpath expressions can be created, in case of plain IFC custom scripts may do the checking, while in case of IFC OWL one can use SHACL (an example is given later). From all these possibilities SHACL is the most promising, as it provides a full validation framework and the most readable format.

Requirements may be evaluated multiple times by multiple people. An evaluation contains the evaluator, the date, and the result, which may be an objective result of a calculation or a subjective ranking or a pass-fail stamp. However, it is assumed that many of the requirements can be checked against the BIM model based on rules generated from the requirements.

As an example, a thermal transmittance requirement is defined on a window:

ex:req01 a bimreq:Requirement;

rdfs:label “Window Requirement 01”@en;

dc:description “Thermal transmittance for the A type windows must be below 1.8”@en;

dc:creator ex:RegulationsOffice;

dc:created “2019-05-26”^^xsd:date;

dc:source ex:A5434Document;

dc:subject “Thermal Transmittance”@en;

bimreq:target ifcowl:IfcWindow;

dc:valid “2021-01-01”^^xsd:date;

Based on this requirement, one can easily generate a BCF comment to pass forward to BIM applications. Furthermore, one can use SHACL to auto-generate compliance reports for the BIM model. The shape expression for the requirement above could look like the following:

ex:WindowShape

a sh:NodeShape;

sh: name “Thermal transmittance checking on windows”@en;

sh:targetClass ifcowl:IfcPropertySingleValue;

sh:filterShape [

sh:property [

sh:path ( ifcowl:name_IfcProperty express:hasString );

sh:hasValue "ThermalTransmittance";

]

];

sh:property [

sh:path ( ifcowl:nominalValue_IfcPropertySingleValue express:hasDouble );

sh:datatype xsd:double;

sh:maxInclusive "1.8"^^xsd:double;

sh:severity sh:Warning;

].

SHACL reports can then be transformed into plain text reports, BCF comments, or spreadsheets, which can either be read by humans or imported into BIM tools for further processing.