A Generalized Adaptive Framework (GAF) for Automating Code Compliance Checking

Abstract

Building design review is the procedure of checking a design against codes and standard provisions to satisfy the accuracy of the design and identify non-compliances before construction begins. The current approaches for conducting the design review process in an automatic or semi-automatic manner are either based on proprietary, domain-specific or hard-coded rule-based mechanisms. These methods may be effective in their specific applications, but they have the downsides of being costly to maintain, inflexible to modify, and lack a generalized framework of rules and regulations modeling that can adapt to various engineering design realms, and thus don’t support a neutral data standard. They are often referred to as ‘Black Box’ or ‘Gray Box’ approaches. This research offers a new comprehensive framework that reduces the limitations of the cited methods. Building regulations, for instance, are legal documents transcribed and approved by professionals to be interpreted and applied by people. They are hardly as precise as formal logic. Engineers, architects, and contractors can read those technical documents and transform them into scientific notations and software applications. They can extract any data they need, reason about it, and apply it at various phases of the project. How these extraction and use are carried out is a critical component of automating the design review process. The chief goal is to address this issue by developing a Generalized Adaptive Framework (GAF) for a neutral data standard (Industry Foundation Classes (IFC)) that enables automating the code compliance checking processes to achieve design efficiency and cost-effectiveness. The objectives of this study comprise i) to develop a theoretical background to an adaptive framework that supports a neutral data standard for transforming the written code regulations and rules into a computable model, and ii) to define the various modules required for computerizing of the code compliance verification process.

1. Introduction

Design review is the process of evaluating a design against its requirements to verify the quality and performance of the design and identify issues before construction takes place. In the Architecture, Engineering, and Construction (AEC) industry, this process is referred to as the Code Compliance Checking (CCC) process. The main goals of this process are to ensure quality, cost-effectiveness and prevent failure of the designed system. Presently AEC industries are becoming increasingly sophisticated, thus, the issue of identifying design defects and shortcomings before assembly and implementation is becoming even more problematic. This is true almost for all engineering design domains, from urban design, aerospace, mechanical, to building and construction engineering. The CCC Process is the primary method used to address this problem by critically assessing all aspects of the design through careful examination of requirements compliance, verification, and analyses.

The design review process is normally conducted at each phase of the design, from the conceptual to the final stage of construction documents. These series of reviews or CCC processes take a considerable amount of time and effort for both designers and building authorities. For building officials, the CCC is even more critical since they are responsible for issuing building permits to start the construction process. Thus, there were some efforts cited in the literature that aimed to automate some of the CCC process [1,2,3]. Most of these efforts are either based on proprietary schemas, domain-specific or hard-coded rule-based representations, which may be successful in their implementations, but they have the shortcomings of being expensive to maintain, inflexible to modify, lack a generalized framework of rules and regulations modeling. They are often referred to as ‘Black Box’ or ‘Gray Box’ approaches.

Advancement of technology has continuously engaged the building design profession over the past several centuries. From the ancient Egyptian models in the form of drawings and physical objects as demonstrated in the plans of the Tomb of Rameses IV and the drawing of the shrine from Ghorâb, four thousand years ago, to the use of the mouse in the early 1970s, to the development of Building Information Modeling (BIM) technology in the mid-nineties, all indicate the radical impact of technology on building design and construction [4].

The last challenging global economic downturn in 2008 accompanied by the continued growth of complexity of building regulations and standards in a fragmented construction industry make designing and delivering of a facility that meets the owner’s objective within budget and schedules into a cumbersome task. The notion of computerization within the context of facility design in the 21st century offers promising solutions in optimizing the building design process. By providing more accurate information in an open and asynchronous data format, computerization offers engineers, architects, and contractors efficient and innovative methods to collaborate, investigate many design alternatives, and validate design assumptions and requirements against code specifications in a virtual environment before construction to achieve optimum design objectives.

The concept of automating the CCC process described in this paper focuses on building regulations compliance checking mechanisms that are defined by the relationship among various design and engineering information management systems and the Building Information Modeling (BIM) and how this computerization will assist in streamlining communication and dissemination of building design review information amongst breadth of stakeholders.

In the AEC industry, specifications and regulations typically take the form of written texts, tables, charts, and equations. These rules, in general, have lawful status. However, the cognitive and analytic ability of the human brain is dissimilar to anything implemented in a computer environment. Thus, the automation of this process poses a real challenge to the AEC industry [5]. For example, how can the interpretation of these rules into a computer interpretable format be performed, in a manner that the implementation can be validated as consistent with the written regulations? Quite often, the process counts on the computer programmer’s interpretation and translation of the written rules into computer code. In other cases, the logic of the human language statements is formally interpreted and then encoded into computer instructions.

Recently, new developments in Artificial Intelligence (AI) research and Building Information Modeling (BIM) could offer practical concepts to resolve some of the current major problems with automating CCC. Building standards and regulations commonly endeavor to organize, categorize, label, and define the rules, actions, and patterns of the built environment to attain safety against any failure, efficiency, and the overall economy. Nevertheless, their best-laid plans are overwhelmed by the inevitable change, growth, innovation, progress, evolution, diversity, and entropy [2]. Quite often regulations can amend provisions and interpretive standards, which generally leads to massive volumes of semi-structured documents that alter, complement and potentially conflict with one another. These issues, which indicate complications for both young designers and engineers as well as experienced professionals, are also far more disorderly for the fragile traditional knowledge bases in computer systems. Notwithstanding that precise definitions and specifications are essential for solving encoding design regulations, many building code provisions aren’t precisely defined and are often characterized by high subjectivity. Furthermore, some code provisions are characterized by continuous progressions and open-ended range of exceptions that make it difficult to give exact definitions for any concepts that are learned through experience.

2. A Brief Review of Recent Researches

This issue of automating rules and regulations checking has interested many researchers and practitioners over the years. The first successful effort to automate design compliance is demonstrated by the work of Fenv [6], when he investigated the application of decision tables to represent the AISC (American Institute of Steel Construction) standard specifications. He remarked that decision tables, If-Then-novel programming, and the program documentation technique, could be used to represent design standard provisions in a precise and unambiguous form. The concept was set to practical application in the 1969 AISC Specification. It was expressed as a set of interrelated decision tables. Later, other researchers tried to build on Fenv work such as Lopez et al., who implemented the SICAD (Standards Interface for Computer Aided Design system [7,8]). The SICAD system was a software prototype developed to demonstrate the checking of designed components as described in application program databases for conformance with design standards. The SICAD concepts were in production use in the AASHTO Bridge Design System [9]. Garrett developed the Standards Processing Expert (SPEX) system [10] using a standard-independent approach for sizing and proportioning structural member cross-sections. The system reasoned with the model of a design standard, represented using SICAD system representation, to generate a set of constraints on a set of essential data items that describe the attributes of a design to be determined.

In summary, over 400 relevant research studies are focusing on automating building codes compliances for design review, traversing more than 40 decades that can be identified. Some of the key recent investigations are summarized in

Table 1. Summary of recent studies related to automating design rules compliance checking.

Reference	Method Description	Limitations
[11,12,13]	Domain-specific approaches for automatic review of building models.	Domain-specific. No support for the open standard. No methods to deal with ambiguous information.
[14,15]	Proposed Deontic conceptualization and logic for representing regulations along with Natural Language Processing (NLP).	No support for the open standard. No methods to deal with ambiguous information.
[16]	AI approach based on NLP techniques for Turkish fire egress codes.	Only applicable for fire egress code. Does not support IFC data schema.
[1,17,18,19,20,21,22,23,24]	Logic rules for expression shared ontologies for semantic representation of building regulations. They proposed the integration and validation of logical rules, RDF and OWL (Web Ontology Language) concepts, N’Logic rules.	Limited expressiveness to cover various parts of the building specifications. No methods to deal with ambiguous information.
[25,26]	Semantic rules for logical expression, Semantic Web Rule Language (SWRL). Feature extraction from building energy analysis sim, integration, validation, mapping data exchanges using SWRL.	No methods to deal with ambiguous information. Domain-specific
[27,28,29]	Used Dynamo plug-in for Autodesk Revit, Visual Programming Languages (VPL) for Automation.	No methods to deal with ambiguous information. Requires programming knowledge. Platform-specific
[30,31]	Semantic rules for logical expression for Evacuation regulation checking according to Korean codes, CORENET.	No generalized approach. No support for open standard. No methods to deal with ambiguous information.
[28,32,33,34]	AI approach based on NLP techniques, semantic NLP-based information extraction from construction regulatory documents through machine learning and text processing.	Back-box approach. No support for open standard. No methods to deal with ambiguous information.

. Most of these suggested methods are backbox or gray-box approaches. Some of these studies are generally associated with a specific domain, such as spatial assessment, structural integrity, safety, energy usage and so on. Some of them offer a certain degree of customization to modify the parameters of each rule to match specific local regulations. Once the rule structure has been encoded, it is available for multiple similar projects. In general, these systems can be classified into three main types of platforms for automated code compliance checking systems:

-

As a software application integrated with a specific design tool, such as a plug-in. It is accessible to verify current model during the design process;

-

As a stand-alone software application detached from the modeling tools. An example of this platform would be Solibri Model Checker (SMC), which has its rule engine that can work on multiple models;

-

As a web-based application which can be available to verify designs from various sources.

As evident from the literature review, most of the proposed systems for automated code compliance auditing are based on proprietary or hard-coded rule-based representations, which may be successful in their domain implementations, but they have many drawbacks related to cost, maintenance and flexibility when used in automating building design review process. This project seeks to develop a new framework that addresses the shortcomings of the existing approaches by providing a computable model with explicit syntax and semantics that can be used to represent and reason about building regulations and provisions based on the neutral data format. Furthermore, the framework offers an object-based representation of building regulations, defines the minimum amount of data required to enable optimum Automatic CCC (ACCC) process.

3. Statement of Purpose

Currently, the manual design review process is time-consuming, error prone, and becoming very costly to sustain. The reasons behind these issues include: (a) increase rate of updates of regulations and standards with new knowledge and research outcomes; (b) new, state of the art technologies, equipment and devices; (c) higher amount of data and its multidisciplinary nature; and (d) increase in hardware/software communications complexity. Moreover, in building design, other issues associated with the manual CCC are lack of consistency in interpretation of regulatory provisions, the ability to properly self-check required aspects before bidding, and the long time needed for approvals of construction permits by building authorities that can have adverse financial impacts on projects.

The cited methods for automated rules compliance auditing in building design are either based on proprietary frameworks, domain-specific areas, or hard-coded rule-based representations. These approaches may be useful in their specific implementations. Nonetheless, they have the disadvantages of being costly to maintain, difficult to change, and the absence of a generalized framework of rules and regulations modeling that can adapt to various domains, and thus don’t support an open neutral standard. Furthermore, the current methods lack the means to deal with subjective and ambiguous building regulations. Most of these systems have not endured the test of industry applications.

4. Goals and Objectives

This research proposes a new approach that addresses the shortcomings of the cited methods. The primary goal is the development of a Generalized Adaptive Framework (GAF) that enables ACCC. The objectives of this research comprise: (1) the development of the theoretical background of a framework that is adaptive to the target domain and supports an open standard for transmuting the written code provisions into computable representations; (2) generating algorithms for the data exchanges between the components of the framework to execute the virtual review process of a building design in order to achieve design accuracy and cost-effectiveness.

5. Methodology: The ACCC Model

Figure 1 depicts the components and stages of the framework development process. In particular, the framework centers on the following levels of development for the ACCC process:

(A) High-Order Level I: Taxonomy formation, knowledge conceptualization, modification, integration, and decomposition of the design regulations and rules. This includes data analysis, partitioning and classification of regulatory text into broad categories. This phase is referred to as Transformation Reasoning Algorithm (TRA) and delineated in Figure 2 and Figure 3.

(B) High-Order Level II: Requires the Development Model View Definition (MVD), leading to Industry Foundation Classes (IFC) schema of the information obtained from phase A. The final data format is ifcXML representation. IfcXML is defined as the XML equivalent to the EXPRESS based specification of the IFC data model.

(C) Higher-order level III: The development of feature extraction algorithm for all objective data (unambiguous data) leading to full translation into the object-based model. This extraction and transformation will lead to ifcXML data object model (see Figure 1).

(D) Lower-order level: Necessitates feature extraction of uncertain data, then employing an algorithm for partial translation using fuzzy logic and approximate reasoning methods. Fuzzy logic provides a means of expressing linguistic rules in such a form that they can be combined into a coherent reasoning model. Such a model consists of three main parts: (i) fuzzification, (ii) inference engine (fuzzy rule base), and (iii) defuzzification (the process of transforming the aggregation result into a crisp output). The resulting data model from this phase is projected to be in ifcXML.

(E) The execution phase, which carries out the communications between the different layers of development. This encompasses the design of algorithms linking the data from (B), (C), (D) and the BIM model. These algorithms will be based on Language-integrated Query (LINQ) programming objects to extract, access and link BIM and regulations data via ifcXML [2]. Also, this phase will produce various output reports such as 2D, 3D views showing objects that are in noncompliance along with the detailed information about the regulation.

The theoretical development of the proposed GAF is based on the framework depicted in Figure 1. The objectives of the framework involve determining the requirements for an interpretation process where the semantic structure of each rule is translated into object expressions or parametric models using the Transformation Reasoning Algorithm (TRA) that would lead to neutral data format such as the Industry Foundation Classes (IFC) data schema. Moreover, the framework outlines the development of algorithms to link these representations and relate to the BIM data being examined.

6. Transformation Reasoning Algorithm (TRA)

The TRA introduces the taxonomy for the building regulations knowledge followed by the conceptualization process. Subsequently, knowledge created will be transformed to a new formalized form to deduce various facts to carry out automated reasoning. For example, regulation or provision X_i will be transformed into a concept Y_i using TRA principles [3]. TRA taxonomy describes the following major concepts: Content (C_i); Provisory (P_i); Dependent (D_i); Ambiguous (A_i) Exceptions (E_i); and Alternatives (Alt_i).

Contents (C_i… C_n) are the sections of the building codes and regulations that cannot be transformed into object rules. These clauses are usually devoted to definitions, such as the definition of types of loads, firewall, fire rate, smoke evacuation, high-rise building, etc. For instance, the live load is defined by the ASCE7-10 standard as: “A load produced by the use and occupancy of the building or other structure that does not include construction or environmental loads, such as wind load, snow load, rain load, earthquake load, flood load, or dead load”.

Provisory (P_i… P_n) are clauses of the regulations that can be transformed from the textual format into a set of object rules. Examples of such clauses are prevalent, and typical structures include rules with specific values such as those given in tables or equations in the building regulations.

Dependent (D_i… D_n) clauses specify that one clause is reliant on one or more other provisions. This means that some requirements are only appropriate for a specific condition when other clauses are satisfied. These clauses generally contain provisory clauses (P_i … P_n) and are often challenging to transform into sets of immediate object rules. These sections quite often may require manual checking for compliance. For instance, in Florida Building Code (FBC 2017), Section 503.1 regarding building height and area, states that “The building height and area shall not exceed the limits specified in Table 503 based on the type of construction as determined by Section 602 and the occupancies as determined by Section 302 except as modified hereafter. Each portion of a build separated by one or more firewalls complying with Section 706 shall be a separate building.”.

Ambiguous (A_i … A_n) clauses are the vague or inexact provisions that would need an expert judgment to be evaluated. They usually include words such as: approximately, about, relatively, close to, far from, maybe, etc. An example of such a provision is the footnote of the design lateral soil pressure for the clause given in ASCE 7-10: “For relatively rigid walls, as when braced by floors, the design lateral soil load shall be increased for sand and gravel type soils to 60 psf (9.43 kPa) per foot (meter) of depth. Basement walls extending not more than 8 ft (2.44 m) below grade and supporting light floor systems are not considered as being relatively rigid walls.” This concept covers all regulations that are not capable of being computerized and some of them may have to be rewritten to enable implementation in an automated compliance auditing environment. Interpretation and rewriting both must adhere to understanding terms from both the legal and construction perspectives.

Exceptions (E_i … E_n) are the clauses that a specific provision excludes. For example, in Florida Building Code 2017-Residential (FBC 2017-R), Section 305.1 (minimum room heights) apply for habitable spaces with three exceptions covering rooms with a sloped roof, the ceiling height above the bathroom, and obstructions in basements containing habitable spaces.

Alternatives (Alt_i … Alt_n) are the alternative code provisions that may apply to a specific regulations. For instance, in the FBC 2017-R, the requirements in Section 301.1 (design criteria application) have the following alternative standards (subject to FBC limitations):

• AF&PA Wood Frame Construction Manual (WFCM).
• AISI Standard for Cold-Formed Steel Framing-Prescriptive Method for One- and Two-Family Dwellings (AISI S230).
• ICC Standard on the Design and Construction of Log Structures (ICC 400).

that can be used.

These concepts can then be modified, combined or decomposed to enable a computable depiction of design regulations and standards. Knowledge concepts X_i can be transformed or integrated with another concept into Y_i, and then Y_i can be transmuted into Z_i to enable efficient computable representation. Thus, the TRA is defined as the conceptualization of knowledge representation by mapping design regulations into sets of object rules. Figure 2 and Figure 3 are pictorial descriptions of the TRA for building design regulations.

Building design regulations will be classified using the taxonomy defined earlier and can also be translated into conceptual representations that closely approximate the meaning of the building code provision. These figurative structures can then be transformed and manipulated to deduce various facts and rules to carry out automated compliance validation. The TRA is partially driven from the first-order logic calculus.

Table 2. The syntax of the Transformation Reasoning Algorithm (TRA).

Symbol	Definition
::=	Is defined as
::∃	Has Exceptions
::◊	Has Alternatives
∧	Conjunction
∨	Disjunction
⊂	Subset of
¬	Negation
∀	Universal Quantifier
∃	Existential Quantifier
∈	Belongs to
→	Implication
↔	Biconditional
⇒	Transform into
::⇒	Depends upon
Constant	String starting with an uppercase letter
Variable	String starting with a lowercase letter
Pred (arg1, arg2, …)	Predicate
Fun (arg1, arg2, …)	Function
Pred1 (arg1, arg2, …) ∧ Pred2 (arg1, arg2, …) ∨ …	Rule

depicts a summary of the syntax for the TRA.

7. Example

The TRA can be exemplified further by considering the Florida Building Code 2017 – Residential (FBC 2017 - R). Figure 4 depicts a section from the FBC 2017-Residential. The provision shown in Figure 4 can be transformed into computable representations using the TRA as follows:

Let REG_i = “Section R305”; Where i varies from 1 to n number of code provisions. Then we have

REG_i ∈ P_i ⇒ Y_i ⇒ X_i

(1)

where the subscript i stands for the counts of the code sections being processed and varies from 1 to n sections. P_i designates that this is a provisory clause, and describes the minimum room area (Y_i) which is given by X_i that expresses the various Rules describing Y_i:

X_i = {R₁, R₂, …R_m}

(2)

where, R₁, R₂, …R_m are the rules defining X_i.

Let Z_1j = {z₁₁…z_1q}

(3)

z = IfcSpace; z₁₁ = “R305.1”;

(4)

z₁₁ ::∃ SlopedCeiling(z) ∧ SpaceName(z, BATHROOM) ∧ ((AtBeamElevation(z) ∨ AtDuctElevations(z)))

(5)

Equation (15) expresses the exceptions stated in the provision of section R305.1 of FBC 2017-R.

z₁₂ ::= ≥ 7 ft ; z₁₃ ::= ≥ 6.667 ft ; z₁₄ ::= ≥ 6.333 ft ; z₁₅ ≥ 5 ft

(6)

R₁: ∀ z (REG_i (z) → CeilingHeight(z, z₁₂) ∧ HabitableSpace(z) ∧ ¬ SpaceName(z, BATHROOM) ∧ ¬ SpaceName(z, TOILETROOM) ∧ ¬ SpaceName(z, LAUNDRYROOM) ∧ ¬ SlopedCeiling(z)

(7)

R₂: ∀ z (REG_i (z) → CeilingHeight(z, z₁₃) ∧ HabitableSpace(z) ∧ (SpaceName(z, BATHROOM) ∨ SpaceName(z, TOILETROOM) ∨ SpaceName(z, LAUNDRYROOM)) ∧ ¬ SlopedCeiling(z)

(8)

A = FloorArea(z); z₁₆ ::= ≥ 0.5 ∗ A

(9)

R₃: ∀ z (REG_i (z) → CeilingHeight(z, z₁₅) ∧ SlopedCeiling(z, z₁₆)

(10)

Let Z_2j = {z₂₁, …, z_2q}; z = IfcSpace; z₂₁ = “R305.1.1”

(11)

z₂₃ ::= ≥ 6.667 ft ; z₂₄ ::= ≥ 6.333 ft; z₂₅ = IfcBeam; z₂₆ = IfcDuct;

(12)

R₄: ∀ z (REG_i (z) → CeilingHeight(z, z₂₃) ∧ ¬ (AtBeamElevation(z, z₂₅) ∨ AtDuctElevations(z, z₂₆)) ∧ ¬ HabitableSpace(z)

(13)

R₅: ∀ z (REG_i (z) → CeilingHeight(z, z₂₄) ∧ (AtBeamElevation(z, z₂₅) ∨ AtDuctElevations(z, z₂₆)

(14)

X_i = {R₁ ∧ R₂ ∧ R₃ ∧ R₄ ∧ R₅}

(15)

Equation (15) expresses section R305 of FBC 2017 - R using TRA.

An example of imprecise building code provisions can be found in section R322.1 of FBC 2017-Residential (see Figure 5). In this provision, the regulations states: “Buildings and structures constructed in whole or in part in flood hazard areas, including A or V Zones and Coastal A Zones, as established in Table R301.2(1), and substantial improvement and restoration of substantial damage of buildings and structures in flood hazard areas, shall be designed and constructed in accordance with the provisions contained in this section.” The word substantial is not defined precisely. Using the TRA, then we have

REG₂ = “Section R322”; then we have: REG₂ ∈ (C₂ ∧ A₂) ⇒ Y₂ ⇒ X₂

(16)

(C₂ ∧ A₂) designates that this is a content clause with ambiguous statements describing flood resistance construction (Y₂) which is given by X₂ that describes the several conditions unfolding Y₂.

X₂ = {R₁, R₂, …R_m}

(17)

where, R₁, R₂, …R_m are the rules defining X₂.

Let Z_2j = {z₂₁, …, z_2q}; z = IfcBuilding; z₂₁ = “FBC 2017 - R322”; z₂₂ = “ASCE 24”

(18)

REG₂ ::◊ z₂₂

(19)

R₁: ∀ z (InFloodZone(z) → RequiredProvision (z, z₂₁))

(20)

R₂: ∀ z (InFloodWays(z) → RequiredProvision (z, z₂₂))

(21)

Next step is to conceptualize the term “substantial damage.” The TRA proposes fuzzy logic and predicates to transmute the concept into a rule expression. A fuzzy set is described by reference [35] as: A is a fuzzy subset of the universe of discourse U, is characterized by a membership function μ_A: U → [0…1] which associates with each element u of U a number μ_A (u) in the interval [0,1]. This definition can be employed to define a fuzzy predicate. The truth-value of any proposition can be evaluated as the degree of membership of the responding fuzzy relation. Thus, a fuzzy predicate can be considered as the membership function of a fuzzy relation over individual variables’ universe of discourse. Each fuzzy predicate characterizes a concept in the TRA. For instance, the building damage stated in section R322 can be represented as a fuzzy variable taking values delineated in Figure 6. In this figure, the x-axis is the degree of building damage (u), while the y-axis represents the membership functioning values μ_A (u). These variables comprise small damage, medium damage, and substantial damage. These descriptions can be determined from experience or given by local guidelines. Now, let z₂₃ = a fuzzy variable defined by

$$\begin{array}{ccc}\hfill {\mu }_A\left(u\right)& =0\hfill & 80\%<=u>=0\hfill \\ \hfill & =(1/15)u-25/15\hfill & 80\%<u>=90\%\hfill \\ \hfill & =1\hfill & u>90\%\hfill \end{array}\}$$

(22)

where, 0 ≤ µ_A(u) ≤ 1.

Next, section R322 of FBC 2017-Residential is transformed into the following rule:

R₃: ∀ z (InFloodZone(z) ∧ Damage (z, z₂₃) → RequiredProvision (z, z₂₁))

(23)

and finally,

X₂ = {R₁ ∧ (R₃ ∨ R₂)}

(24)

Equation (24) signifies section R322 of FBC 2017 - R using the TRA.

Engineering design codes do rather frequently use such vague terms to describe certain conditions.

Table 3. Common ambiguous terms in building regulations.

No	Uncertain Building Code Terms	Conceptualization
1	The building has Some damage	Fuzzy predicate, 0 ≤ µA(u) ≤ 1; Figure 5c
2	The building has a good amount of damage	Fuzzy predicate, 0 ≤ µA(u) ≤ 1; Figure 5d
3	Building damage is extreme	Fuzzy predicate, 0 ≤ µA(u) ≤ 1; Figure 5g
4	A substantial amount or a sizable amount	Fuzzy predicate, 0 ≤ µA(u) ≤ 1; Figure 5f
5	A fair amount or Moderate amount	Fuzzy predicate, 0 ≤ µA(u) ≤ 1; Figure 5d
6	Large value	Fuzzy predicate, 0 ≤ µA(u) ≤ 1; Figure 5e
7	Small amount	Fuzzy predicate, 0 ≤ µA(u) ≤ 1; Figure 5b
8	Very little or a little bit	Fuzzy predicate, 0 ≤ µA(u) ≤ 1; Figure 5a

recapitulates some of these terms and their transformation using a fuzzy predicate. For example, the fuzzy term “very little damage” in Table 3 is represented graphically by Figure 6a. This figure describes building damages in the range of 0% to 20%. The membership function has a maximum value of 1.0 for the degree of damages from 0% to 10% and then decreases linearly to 0 for a degree of damage of 20%.

8. Implementation Algorithms

This phase addresses designing and implanting data communicating algorithms for exchanging and presenting the results of the proposed GAF framework. It utilizes Language-integrated Query (LINQ) programming objects to extract, access and link BIM and regulations data via ifcXML [2]. Figure 7 delineates a part of the proposed algorithms. The implementing of the IFC standard using XML (eXtensible Markup Language) technologies is known as ifcXML. It is an extension of the existing IFC data format. It focuses on the specifics of the ifcXML specification compared to the standard EXPRESS based IFC object data model. The ifcXML data files are given the extension “.xml” or alternatively “.ifcxml”. Figure 8 depicts the process of generating an ifcXML data file.

To provide evidence for the Proof of Concept (POC), a two-story building is considered in a typical design review process examining regulations and provisions from FBC-R 2017. The building is the duplex apartment model that is provided by the BuildingSmart Alliance website and delineated in Figure 9. Some of the Ifc objects that will be involved in this example are illustrated in Figure 10.

In this construction, the ifcSpace functions as the primary object and is essential to configure the spatial structure of a building. The spatial structure elements are connected by using the object relationship ifcRelAggregates. Moreover, it offers additional functions such as serving as the spatial container for space-related elements. Space is normally linked to a building storey (or in case of exterior spaces to a site). Space can cover several connected spaces. Thus, a space group provides a collection of spaces included in a building story. Space may also be fragmented into elements, where each element defines a partial space. This is defined by the composition type attribute of the supertype ifcSpatialStructureElement.

Figure 7 displays a part of the C# code of the proposed GAF. Line 1 in Figure 6 reads the data from the ifcXML file of the BIM model of the building shown in Figure 9. Lines 8 to 17 determine the floor and areas and the height of each space in the building. Line 19 in Figure 11 reads the code provisions from the ifcXML data file of the FBC 2017. In Figure 11, line 22 to line 31 deals with examining the compliance of the areas of the spaces as well as the net and gross floor areas according to the FBC-2017.

Figure 12a delineates the results of checking the areas of the spaces in the example building shown in Figure 9 using the GAF. Figure 12b illustrates the floor plan view of level 1 of the duplex apartment building (see Figure 9) being used for this example of automated compliance verification of Florida’s residential building regulations.

9. Conclusions

The computerization of the code compliance checking process presents a challenge for the AEC industry. This is greatly attributed to the fact that many sections of the building rules take the form of written texts. The present approaches for computerization or semi- computerization of rules compliance verification used in a design review are either based on proprietary, domain-specific or hard-coded rule expressions, which can be successful in their specific applications. Nonetheless, most of these methods are expensive to maintain, inflexible to change, the absence of a comprehensive framework of regulations modeling that can adapt to various domains, and thus they lack IFC standard support.

This paper offers a generalized adaptive framework (GAF) for automating or semi-automating the code compliance verification process which is based on an object-driven representation of building rules that can deal with certain and uncertain data and transform code and standards regulations into computable expressions using the Transformation Reasoning Algorithm (TRA). The framework is flexible and can adapt to various engineering design disciplines.

The paper introduces and delineates the various constituents of the proposed GAF and their relationships. The TRA introduces the taxonomy for the building regulations knowledge along with the conceptualization and transformation processes. Subsequently, knowledge created is a new formalized object representation that models objective and ambiguous building regulations and can deduce various facts to carry out automated reasoning. This approach minimizes the shortcomings of the cited methods by transforming objective and vague data of building code into a concise formal representation that can be mapped into IFC data schema.

The GAF provides communicating algorithms for exchanging data between the main components of the framework. It utilizes Language-integrated Query (LINQ) programming objects to extract, access and link BIM and regulations data via ifcXML. The application of the proposed GAF has been demonstrated using an example of a two-story building that is considered in a typical design review process, examining regulations and provisions from FBC-R 2017. Thus, it is expected that the research results will have broader impacts that include the enormous benefits to the AEC industry due to the consistency of the interpretation of regulatory provisions, the ability to self-check required aspects before bidding, the time and resources saved during design review, the optimum design, the quicker turnaround in feedback, and faster approvals for construction permits by building authorities.