Architecture of BIM-Based Automated Building Regulations Inspection
(1) Building Model Preparation
When conducting regulatory testing, the building model being tested must align with detectable response data. The naming conventions used for objects usually follow specific legal terminology regulations. Therefore, during the building model creation stage, it is essential to have clear standards that guide designers in creating models compliant with regulatory verification.
Providing a template file with pre-defined naming standards for regulatory attributes is a key preparation step for creating a testable building model. Additionally, ensuring the data quality of the prepared model is a critical concern.
(2) Rule Interpretation
The relationship between “model preparation” and “regulation interpretation” can be described using the concept of “integration.” Here, “internal integration” refers to model preparation, while “external integration” pertains to interpreting regulations.
Interpreting regulations requires a combination of expertise in building regulations and information technology, particularly programming design. Among these, knowledge of building regulations is paramount, with IT serving as a support.
Currently, there are two main approaches to this process:
- Programmers directly encode regulations into software modules using general programming languages. However, since most programmers are not experts in building regulations, this can lead to misunderstandings and errors.
- Regulations, originally described in natural language, are formalized and then converted into executable programming languages. This method involves regulatory experts interpreting regulations logically, breaking them down into deductive steps, and then handing over these logical descriptions to programmers for software implementation. This approach is generally more reliable.
During the translation of regulations, first-order logic is a promising method for logical description. A “predicate” is a well-defined term or function that facilitates clear requirement definitions and can be easily converted into standard procedural syntax.
Regulatory conversion mainly involves two elements:
- Conditions and content of the regulation
- Attributes related to the regulatory effects, which are closely tied to the names and properties of objects
For example, Solibri manages conditions as rule sets and designs attributes as parameterized tables used during detection.
In the long term, two language development paths should be considered:
- Translating laws and regulations into predicate logic descriptions, then converting these into executable program code.
- Developing domain-specific programming languages (rule-based) that allow regulations to be easily defined and implemented for testing, such as the BERA language.
(3) Rule Execution
Once the model and rules are prepared, the detection process can begin. This stage focuses on managing the execution workflow.
Before formal regulatory testing, it is necessary to perform a syntactic check on the building model to verify the presence of required attributes, correct naming conventions, and necessary objects. Whether testing the entire model or a subset view relevant to certain inspection rules, these checks are essential.
Additionally, key tasks during execution include:
- Ensuring regulatory completeness during testing
- Managing model version consistency
(4) Output Results (Rule Reporting)
Currently, the output results approach used by tools like Solibri Model Checker includes:
- Graphical reporting of rule instances
- Referencing the source regulation for each detected issue
Looking ahead, a more proactive approach should be developed—one that automatically suggests corrections to the model view for parts violating regulations. This would directly assist architects in adjusting their designs, saving time and improving compliance.
Must log in before commenting!
Sign Up