Intelligent BIM model verification rule base method and system with self-correction function

Abstract

The invention discloses an intelligent BIM model verification rule base method and system with a self-correction function. The method comprises the steps that a verification rule table, a component classification table, an attribute structure table, a verification task table and a verification result table are designed, and a full-link data relation is established; constructing a'parent component-child component-attribute-expression 'attribute tree structure relationship, and storing the attribute tree structure relationship; creating a BIM model attribute data preprocessor, and outputting a format consistent with the constructed component attribute tree structure; performing comparison verification on the preprocessed BIM attribute data and data in a verification rule table, and then recording and storing a verification result; the verification result is analyzed and counted, the verification rule exceeding the preset threshold value is automatically corrected and calibrated, the correction state is marked, and therefore dynamic optimization of the rule is achieved. According to the method, dynamic self-optimization of the rule can be realized, multiple scenes are adapted, the verification precision and efficiency are improved, and the whole process is traceable.

Description

Technical Field

[0001] This invention relates to the field of information technology in building engineering, specifically to a method and system for a self-correcting intelligent BIM model review rule base, which is particularly suitable for scenarios involving automatic verification of building component attributes based on industry standards. Background Technology

[0002] With the development of Building Information Modeling (BIM) technology, the application of BIM models in engineering design, construction, and operation and maintenance is becoming increasingly widespread. Model verification, as a crucial step in ensuring the accuracy of BIM models, has a significant impact on project quality. Currently, existing BIM model verification technologies mainly rely on pre-set fixed rule bases, which have the following shortcomings: 1. Insufficient flexibility of the rule base: The existing review rule base is mostly statically set and cannot be dynamically adjusted according to the actual verification results. When the engineering scenario changes (such as concrete structures in different environmental categories) or industry standards are updated, the rules need to be manually modified, which is not only inefficient, but also prone to errors due to human operation.

[0003] 2. Poor compatibility with multiple standards: The construction industry has a variety of sub-standards (such as the requirements for different environmental categories in the "Code for Design of Concrete Structures"). The existing rule base is difficult to adapt to multiple scenario standards quickly, and rules need to be built separately for each scenario, resulting in rule redundancy and high maintenance costs.

[0004] 3. Low verification accuracy and efficiency: Component classification and attribute matching rely on manual definition, which is prone to problems such as missing classifications and inconsistent attribute names, resulting in "missed detections" or "false detections" during verification. At the same time, the verification results are disconnected from rule optimization, and it is impossible to improve the rationality of the rules through historical data feedback.

[0005] 4. Weak traceability and maintainability: Existing technologies lack a full-process record of the verification process and rule modification. When the verification result is abnormal, it is difficult to trace the root cause of the problem. In addition, there is no historical record of rule modification, which is not conducive to later maintenance and auditing. Summary of the Invention

[0006] To overcome the shortcomings of the above technologies, this invention provides a method and system for a self-correcting intelligent BIM model review rule base, which can achieve efficient and accurate review of BIM models.

[0007] Terminology Explanation: 1. JSON: JavaScript Object Notation. JSON is a lightweight data interchange format that is easy for humans to read and write, and also easy for machines to parse and generate.

[0008] 2. OBD: OpenBuildings Designer is a multidisciplinary architectural design software that enables Building Information Modeling (BIM) workflows to provide information-rich models for architectural design, analysis, simulation, and documentation.

[0009] The technical solution adopted by this invention to overcome its technical problems is: A method for a self-correcting intelligent BIM model review rule base includes: Construct a data storage structure: Design a verification rule table, a component classification table, an attribute structure table, a verification task table, and a verification result table, and establish a full-link data relationship of "verification rule - component classification - attribute - verification task - verification result"; Build and store the rule standards: Build rule standards based on industry specifications and for different engineering scenarios, and then store the rule standards in the validation rule table; Constructing and storing component attribute trees: Extract parent-level categorized components, child-level categorized components, component attribute names, and attribute value constraint expressions from industry standards; construct the "parent component-child component-attribute-expression" attribute tree structure relationship of the BIM model; encapsulate it into a standardized component rule verification template; and store it in the database. BIM model data preprocessing: Create a BIM model attribute data preprocessor, which repackages the acquired BIM model attribute data to output a format consistent with the constructed component attribute tree structure. Perform intelligent verification: Initiate a BIM model verification task, compare the pre-processed BIM model attribute data with the data in the verification rule table, and then record and store the verification results in the database. Rule self-correction mechanism: Analyze and statistically analyze the verification results, automatically correct and calibrate verification rules that exceed the preset threshold and mark the correction status, thereby realizing dynamic optimization of rules.

[0010] Furthermore, the validation rule table is used to store the imported initial rule data and the custom rule data; the fields included in the validation rule table are rule primary key id, rule name, rule description, creator, creation time, updater, update time, and deletion status; The component classification table is used to enter the specified component classification data and match whether the BIM model components to be verified meet the classification standards. The component classification table includes the following fields: component classification primary key id, rule id, parent classification id, classification name, calibration flag, creator, creation time, updater, update time, and deletion status. The attribute structure table is used to enter the specified component attribute data, determine the attribute verification type, and match the attribute name of the component. The fields included in the attribute structure table are: attribute primary key id, component category id, attribute name, attribute verification type, function expression, calibration flag, creator, creation time, updater, update time, and deletion status. The verification task table is used to record information related to the rule verification task after it is initiated, as well as the execution status of the task. The fields included in the verification task table are: primary key id of the verification task, id of the rule to which it belongs, verification status, creator, creation time, and task completion time. The verification result table is used to record the result information after the verification task is completed. The fields included in the verification result table are: task ID, ID corresponding to the verification component attribute, ID corresponding to the verification component category, verification result, original data record of component attribute, and specific reason for verification result.

[0011] Furthermore, a complete data relationship is established, consisting of "verification rules - component classification - attributes - verification tasks - verification results," including the following: The entire data relationship is linked by primary keys, constructing a closed-loop logic from "validation rule definition" to "validation result output". The specific relationships between each link are as follows: Association between validation rules and component categories: The component category table uses the primary key id of the validation rule table as a foreign key, and all component categories belonging to the same rule are uniformly linked to the corresponding rule to realize the association logic of "one rule corresponds to several component categories". Association between component categories and attributes: The attribute structure table uses the primary key id of the component category table as a foreign key to bind each attribute to the component category of the attribute, forming a hierarchical relationship of "one component category corresponds to several attributes". Association between verification rules and verification tasks: When initiating a verification task, the primary key id of the target verification rule table must be specified so that each verification task is associated with a specific verification rule, clarifying the verification basis of the task and realizing the business logic of "one verification rule initiating several verification tasks". Association between verification tasks and verification results: The verification result table uses the primary key id of the verification task table as a foreign key, binding the verification results generated by each verification task to the verification task itself, forming a mapping relationship of "one verification task corresponds to several verification results".

[0012] Furthermore, the rules and standards are constructed and stored in the database, specifically including: (1) Define rule metadata: Rule Name: Define a rule name for the required engineering scenario, which will be used for subsequent display on the UI and user selection; Rule Description: Include a text description explaining the basis, purpose, and content of the established rule standard; (2) Standard rules are entered into the database: Generate a unique identifier: Generate a globally unique verification rule ID and store the verification rule ID in the primary key field id of the verification rule table, which serves as the unique identity of this rule in the system; Write core information: Store the defined rule name in the rule name field and the rule description in the rule description field; (3) Record management information: Creation time: The current time is automatically obtained through a database function and stored in the creation time field; Status Management: Set the value of the delete status field to indicate whether the data for this rule is available.

[0013] Furthermore, the component attribute tree is constructed and stored in the database, specifically including: Extract parent-level category components, child-level category components, component attribute names, and attribute value constraint expressions from industry rules and standards to form a four-level attribute tree structure relationship of "parent component-child component-attribute-expression" in the BIM model, and encapsulate it into a standardized component rule verification template; The extracted parent and child components are stored in a component category table, and the attributes and expressions are stored in an attribute structure table. Furthermore, the relationships between the data are established, as follows: The relationship between parent and child components: Within the component category table, self-associations are established through the parent category id field. Each component category has one record in the component category table and a unique primary key id. When a component is a child of another component, the parent category id field of the child record is set to the id of its parent component record. The parent category id of the top-level parent structure is set to empty to identify it as the root node. The relationship between components and attributes: In the component attribute table, the component category id field is linked to the primary key id of the component category table. Each record in the component attribute table represents a specific attribute, and each attribute belongs to a component category. Therefore, the component category id field of the attribute record is set as the primary key id of the attribute component category in the component category table, establishing a one-to-many relationship of "one component category has multiple attributes".

[0014] Furthermore, BIM model data preprocessing specifically includes: Extract the JSON data of the BIM model components to be verified, and analyze and extract the JSON data; Based on the analysis and extraction of JSON data, the original component data is extracted, the structure is reassembled, and the original JSON data is written into the "parent component-child component-attribute-attribute value" data structure.

[0015] Furthermore, intelligent verification is performed, specifically including: Initiate a BIM model verification task and enter it into the task database as a record of the initiating verification task. After the initial task data is entered into the database, the BIM model attribute verification begins. The preprocessed BIM model component information is compared and verified with the rule template data in the selected verification rule table by component classification, component attribute name, and attribute value. After the verification is completed, the verification results are recorded and stored in the database for future viewing and analysis.

[0016] Furthermore, the rule self-correction mechanism specifically includes: The obtained verification results are analyzed and statistically analyzed. The verification failure rate of each component is calculated for eight categories of result sets: missing parent component, incorrect parent component name, missing child component, incorrect child component name, missing component attribute, incorrect component attribute name, missing component attribute value, and incorrect component attribute value. If the failure rate of the corresponding attribute value under a certain component exceeds the preset threshold, the function expression under the corresponding attribute of this component will be automatically corrected and calibrated. Update the database with the revised rules and mark the revision status.

[0017] This invention also discloses an intelligent BIM model review rule base system with self-correction function, comprising: The data storage module is configured to store the verification rule table, component classification table, attribute structure table, verification task table, and verification result table, and to establish a full-link data relationship of "verification rule - component classification - attribute - verification task - verification result". The rule standard construction module is configured to build rule standards based on industry specifications and for different engineering scenarios, and then store the rule standards in the validation rule table; The component attribute tree construction module is configured to extract parent-level categorized components, child-level categorized components, component attribute names, and attribute value constraint expressions from industry standards, construct the "parent component-child component-attribute-expression" attribute tree structure relationship of the BIM model, encapsulate it into a standardized component rule verification template, and store it in the database. The BIM model data preprocessing module is configured to create a BIM model attribute data preprocessor. The BIM model attribute data preprocessor repackages the acquired BIM model attribute data to output a format consistent with the constructed component attribute tree structure. The intelligent verification execution module is configured to initiate BIM model verification tasks, compare the pre-processed BIM model attribute data with the data in the verification rule table, and then record and store the verification results in the database. The rule self-correction module is configured to analyze and statistically process the verification results, automatically correct and calibrate verification rules that exceed preset thresholds, and mark the correction status, thereby achieving dynamic optimization of the rules.

[0018] The beneficial effects of this invention are: 1. Dynamic self-optimization of rules: Through a self-correction mechanism, rules (such as attribute constraint expressions) are automatically adjusted based on the verification results, reducing manual intervention, solving the problem of poor adaptability of static rule bases, and continuously improving verification accuracy.

[0019] 2. Highly efficient adaptation to multiple scenarios: Supports the construction of rule standards based on different industry specifications and different engineering scenarios, and can quickly switch to adapt to multiple engineering scenarios, reducing rule redundancy and maintenance costs.

[0020] 3. Improved verification accuracy and efficiency: Through standardized component attribute trees and data preprocessing, accurate matching between BIM models and rules is achieved, reducing missed and false detections. This enables automated verification and result analysis processes, significantly improving review efficiency.

[0021] 4. Full-process traceability: The verification process and rule modification history are recorded through the verification task table and verification result table, which facilitates tracing the root cause of problems and supports project auditing and rule optimization review.

[0022] 5. Strong scalability: The rule base structure is flexible and can be quickly expanded with the updates of industry standards to meet the needs of continuous development of construction engineering technology. Attached Figure Description

[0023] Figure 1 This is a flowchart of the intelligent BIM model review rule base method with self-correction function as described in an embodiment of the present invention. Detailed Implementation

[0024] To facilitate a better understanding of the present invention by those skilled in the art, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The following are merely exemplary and do not limit the scope of protection of the present invention.

[0025] This invention provides a method for a self-correcting intelligent BIM model review rule base, such as... Figure 1As shown, it includes the following steps: Construct a data storage structure: Design a verification rule table, a component classification table, an attribute structure table, a verification task table, and a verification result table, and establish a full-link data relationship of "verification rule - component classification - attribute - verification task - verification result"; Build and store the rule standards: Build rule standards based on industry specifications and for different engineering scenarios, and then store the rule standards in the validation rule table; Constructing and storing component attribute trees: Extract parent-level categorized components, child-level categorized components, component attribute names, and attribute value constraint expressions from industry standards; construct the "parent component-child component-attribute-expression" attribute tree structure relationship of the BIM model; encapsulate it into a standardized component rule verification template; and store it in the database. BIM model data preprocessing: Create a BIM model attribute data preprocessor, which repackages the acquired BIM model attribute data to output a format consistent with the constructed component attribute tree structure. Perform intelligent verification: Initiate a BIM model verification task, compare the pre-processed BIM model attribute data with the data in the verification rule table, and then record and store the verification results in the database. Rule self-correction mechanism: Analyze and statistically analyze the verification results, automatically correct and calibrate verification rules that exceed the preset threshold and mark the correction status, thereby realizing dynamic optimization of rules.

[0026] To better understand the above technical solutions, exemplary embodiments of the present invention will be described in detail below with reference to the accompanying drawings. These are merely exemplary embodiments of the present invention; however, it should be understood that the present invention can be implemented in various forms and is not limited to the embodiments described herein. These embodiments are provided to enable those skilled in the art to understand the present invention more clearly and thoroughly. Example 1:

[0027] The intelligent BIM model review rule base method with self-correction function described in this embodiment includes: S1. Construct data storage structure: Design verification rule table, component classification table, attribute structure table, verification task table, and verification result table, and establish a full-link data relationship of "verification rule - component classification - attribute - verification task - verification result".

[0028] In this embodiment, to achieve attribute verification of BIM model files, five core data tables need to be designed: verification rule table, component classification table, attribute structure table, verification task table, and verification result table.

[0029] Specifically, the verification rule table is used to store the imported initial rule data and the custom rule data. The fields included in the verification rule table are rule primary key id, rule name, rule description, creator, creation time, updater, update time, and deletion status, as shown in Table 1. Among them, the deletion status field serves as a logical deletion flag. 0 means not deleted, indicating that the record is valid; 1 means deleted, indicating that the record is logically invalid but retained in the database for data auditing and accidental deletion recovery to avoid abnormal physical deletion of associated data.

[0030] Table 1 Schematic Diagram of the Structural Field Design of the Verification Rule Table

[0031] Specifically, the component classification table is used to enter the specified component classification data and match whether the BIM model components to be verified conform to the classification standard. The fields included in the component classification table are component classification primary key id, belonging rule id, parent classification id, classification name, calibration flag, creator, creation time, updater, update time, and deletion status, as shown in Table 2.

[0032] Table 2 Schematic Diagram of the Structural Field Design of the Component Classification Table

[0033] Specifically, the attribute structure table is used to enter the specified component attribute data, determine the attribute verification type, and match the attribute names of the components. The fields included in the attribute structure table are attribute primary key id, component classification id, attribute name, attribute verification type, function expression, calibration flag, creator, creation time, updater, update time, and deletion status, as shown in Table 3. Among them, the function expression specifies a specific range in which a certain attribute value meets the standard. For example, for a certain building project, it is stipulated that for component beams, the diameter range between 300mm and 400mm is qualified. Then the function expression in this data table is 300mm < X < 400mm, and the verification result is judged through the execution result of this function expression.

[0034] Table 3 Schematic Diagram of the Structural Field Design of the Attribute Structure Table

[0035] Specifically, the verification task table takes one initiation of a rule verification as one execution task and is used to record the information related to the task after the initiation of the rule verification task and the execution status of the task. The fields included in the verification task table are verification task primary key id, belonging rule id, verification status, creator, creation time, and task completion time. Through the verification task table, the rules selected for this verification, the verification result, and the time spent on the verification can be captured, as shown in Table 4.

[0036] Table 4 Schematic Diagram of the Structural Field Design of the Verification Task Table

[0037] Specifically, after the BIM model verification is completed, corresponding result data is generated, with one attribute corresponding to one verification result. The verification result table is used to record the result information after the verification task is completed. The verification result table includes fields such as the task ID, the ID corresponding to the verified component attribute, the ID corresponding to the verified component category, the verification result, the original data record of the component attribute, and the specific reason for the verification result, as shown in Table 5.

[0038] Table 5. Schematic diagram of the structure fields of the verification result table

[0039] In this embodiment, after designing the above five types of core data tables, it is necessary to establish the relationships between them, that is, to establish a full-link data relationship of "validation rules - component classification - attributes - validation tasks - validation results". The full-link data relationship is linked by primary keys, constructing a closed-loop logic from "validation rule definition" to "validation result output". The relationships between each link are precise and hierarchical. The specific relationships between each link are as follows: Association between validation rules and component categories: The component category table uses the primary key id of the validation rule table (i.e., the rule primary key id) as a foreign key, and all component categories belonging to the same rule are uniformly linked to the corresponding rule to realize the association logic of "one rule corresponds to several component categories" so as to clarify the rule to which each component category belongs.

[0040] Association between component categories and attributes: The attribute structure table uses the primary key id of the component category table (i.e., the primary key id of the component category) as a foreign key to bind each attribute to the component category of the attribute, forming a hierarchical relationship of "one component category corresponds to several attributes" to ensure accurate matching between attributes and component categories.

[0041] Association between verification rules and verification tasks: When initiating a verification task, the primary key ID of the target verification rule table (i.e., the rule primary key ID) must be specified to associate each verification task with a specific verification rule, clarify the verification basis of the task, and realize the business logic of "one verification rule initiates several verification tasks".

[0042] Association between verification tasks and verification results: The verification result table uses the primary key id of the verification task table (i.e., the primary key id of the verification task) as a foreign key to bind the verification results generated by each verification task to the verification task itself, forming a mapping relationship of "one verification task corresponds to several verification results", so as to ensure that the verification results can be traced back to the specific verification task.

[0043] S2. Construct and store rule standards: Construct rule standards based on industry specifications and for different engineering scenarios, and then store the rule standards in the validation rule table.

[0044] To be applied in practical engineering industries, different rules and standards need to be established to adapt to the different requirements of different engineering scenarios. For example, BIM models have different specifications and standards under different environmental categories. Taking concrete structures as an example, the environmental categories exposed to concrete structures are divided into five categories: Category 1 is dry indoor environment, etc.; Category 2a is humid indoor environment, etc.; Category 2b is alternating wet and dry environment, etc.; Category 3a is the environment of severely cold and cold regions where the water level is frozen in winter, etc.; Category 3b is saline soil environment, etc.; Category 4 is seawater environment; and Category 5 is the environment affected by human or natural corrosive substances.

[0045] Therefore, rule verification standards need to select different verification rules based on the actual building environment, and then the rule standards are entered into the database.

[0046] This embodiment takes the "indoor dry environment" rule for constructing concrete structures as an example for database entry. The specific implementation process is as follows: S21. Define rule metadata: (1) Rule name: Use “Indoor Dry Environment Verification Rule” as the rule name, so as to be displayed on the UI interface and to select the rule for verifying BIM model components in the indoor dry environment.

[0047] (2) Rule description: Set a text description to explain the basis, purpose and content of the set rule standard.

[0048] S22. Rule standards are entered into the database. The rule standards are written into the validation rule table. The specific process is as follows: (1) Generate a unique identifier: Generate a globally unique verification rule ID using the IdUtil.getSnowflake() method of the Hutool component, and store the verification rule ID in the primary key field id of the verification rule table as the unique identity of this rule in the system; (2) Write core information: Store the rule name "Indoor Dry Environment Verification Rule" defined in step S21 into the rule name field, and store the rule description set in step S21 into the rule description field.

[0049] S23. Record management information: (1) Creation time: The current time is automatically obtained through the database function CURRENT_TIMESTAMP and stored in the creation time field; (2) Status Management: The value of the deletion status field is set to indicate whether the data of this rule is available. The default value is 0, which means that the rule is available.

[0050] The rules and standards for indoor dry environment scenarios have been entered into the database, and the different rules and standards for other scenarios are entered into the database in the same way.

[0051] S3. Construct and store the component attribute tree: Extract parent category components, child category components, component attribute names and attribute value constraint expressions from industry standards, construct the attribute tree structure relationship of "parent component-child component-attribute-expression" in the BIM model, encapsulate it into a standardized component rule verification template, and store it in the database.

[0052] In this embodiment, step S3 specifically includes: S31. Extract parent-level categorized components, child-level categorized components, component attribute names, and attribute value constraint expressions from industry rules and standards to form a four-level attribute tree structure relationship of "parent component - child component - attribute - expression" in the BIM model, and encapsulate it into a standardized component rule verification template. The extracted unified rules are to extract the component parent name, component child name, component attribute name, and attribute value constraint conditions, which are used as extracted standard values ​​to construct verification rules. The following uses the "Code for Design of Concrete Structures" industry standard as an example to implement specific semantic analysis operations and extract the standard's verification rules.

[0053] In this embodiment, the industry standard "Code for Design of Concrete Structures" is used as an example. The rule file is extracted according to predetermined standard values, which include component parent classification, component child classification, component attributes, and calculation logic formula information. This embodiment takes the extraction of cross-sectional dimension compliance and floor slab thickness restrictions as examples; the following are the results extracted based on the standard values.

[0054] 1. A provision in the "Code for Design of Concrete Structures" states that the ratio of the section height h to the span l of a flexural member must satisfy h ≥ l / 12 (simply supported beam) and h ≥ l / 15 (continuous beam). The following is the specific extracted content based on the extracted code values: (1) Extract component classification: The parent component is a bending component; (2) Extract the corresponding child components under the parent component, which are simply supported beams and continuous beams respectively; (3) Extract the component attribute name under the sub-component: the ratio of section height h to span l; (4) Extract the corresponding function expression under the component attribute name: According to the requirement that the ratio of the section height h to the span l of a simply supported beam must satisfy h≥l / 12, the function expression for extracting the ratio of the section height h to the span l of a simply supported beam is X≤12; similarly, the function expression for extracting the ratio of the section height h to the span l of a continuous beam is X≤15.

[0055] 2. One provision in the "Code for Design of Concrete Structures" states that the minimum thickness for one-way slabs is 60mm, and the minimum thickness for two-way slabs is 80mm. The following is the extracted content based on the extracted code value: (1) Extract component classification: The parent component is the floor slab; (2) Extract the corresponding child components under the parent component, which are one-way slabs and two-way slabs respectively; (3) Extract the component attribute name under the child component: minimum thickness; (4) Extract the function expression corresponding to the component attribute name: for one-way plates, the function expression for minimum thickness is X≥60mm; for two-way plates, the function expression for minimum thickness is X≥80mm.

[0056] 3. A provision in the "Code for Design of Concrete Structures" states that the stirrups in a circular column at beam-column joints should have 135° hooks at their ends. The following is the extracted content based on the extracted code value: (1) Extract component classification: The parent component is a beam-column node; (2) Extract the corresponding child components under the parent component, which are stirrups; (3) Extract the component attribute name under the child component: end hook angle; (4) Extract the text-based function expression corresponding to the end hook angle of the component attribute name, X = "The end should be made into a 135° hook".

[0057] The above are the extracted component data types specified in this embodiment, including parent category components, child category components, component attribute names, and corresponding attribute value constraint expressions. Other specifications also follow this specified extracted data type to form a clear four-level attribute tree structure of "parent component-child component-attribute-expression" to facilitate the subsequent data entry and verification algorithm implementation in this embodiment.

[0058] S32. Store the extracted parent and child components in the component category table, store the attributes and expressions in the attribute structure table, and establish the relationships between the data. The specific relationships between the data are as follows: The relationship between parent and child components: Within the component category table, self-associations are established through the parent category id field. Each component category has one record in the component category table and a unique primary key id. When a component is a child of another component, the parent category id field of the child record is set to the id of its parent component record. The parent category id of the top-level parent structure is set to empty to identify it as the root node.

[0059] The relationship between components and attributes: In the component attribute table, the component category id field is linked to the primary key id of the component category table. Each record in the component attribute table represents a specific attribute, and each attribute belongs to a component category. Therefore, the component category id field of the attribute record is set as the primary key id of the attribute component category in the component category table, establishing a one-to-many relationship of "one component category has multiple attributes".

[0060] The following is the specific implementation process for importing the component specification data extracted in step S31 into the database: 1. Write about bending members 1.1. Component data is imported into the database and written to the component classification table: (1) Parent component category writing: The component category ID is generated by the IdUtil.getSnowflake() method of the Hutool component to ensure global uniqueness and is stored in the id field (i.e. the component category primary key id field) of the component category table; The parent component category value of bending component is written into the category name field; (2) Write the verification rule ID entered in step S22 into the rule ID of this data, as the association between this component classification data and its corresponding rule verification standard; (3) Sub-level component classification is written. The component classification ID is generated by the IdUtil.getSnowflake() method of the Hutool component to ensure global uniqueness and is stored in the id field (i.e. the component classification primary key id field) of the component classification table. The sub-level component classification value of simply supported beam is written into the classification name field. The id of the parent component classification of bending member is stored as the parent classification id of the sub-level component classification in the parent classification id field of the table data. Similarly, the sub-level component classification value of continuous beam is written into the classification name field. The id of the parent component classification of bending member is stored as the parent classification id of the sub-level component classification in the parent classification id field of the table data.

[0061] 1.2. The attributes of simply supported beam members are entered into the database and written into the attribute structure table: (1) Write the attributes of simply supported beam components. Generate the component attribute ID through the IdUtil.getSnowflake() method of the Hutool component to ensure global uniqueness and store it in the attribute primary key ID field; (2) Write the ratio of the component attribute name section height h to the span l into the attribute name field; (3) Write the simply supported beam component ID corresponding to this component attribute into the component category ID field to correspond to the association between this component attribute information and the corresponding simply supported beam component category; (4) Writing the function expression: Write the extracted function expression X≤12 into the function expression field as the calculation expression for the validation attribute value; (5) Function expression type writing: The type of the expression is determined based on the function expression. If the input value is a real number, 1 is written into the attribute validation type field. Different attribute validation types have different logic in the subsequent validation logic algorithm, so this record is made when entering the database. (6) The creation time of the component category is automatically obtained by the database function CURRENT_TIMESTAMP and written into the creation time field to record the writing time of this attribute data.

[0062] 1.3. The attributes of continuous beam members are entered into the database and written into the attribute structure table: (1) Write the continuous beam component attributes. Generate the component attribute ID through the IdUtil.getSnowflake() method of the Hutool component to ensure global uniqueness and store it in the attribute primary key ID field; (2) Write the ratio of the component attribute name section height h to the span l into the attribute name field; (3) Write the continuous beam component ID corresponding to this component attribute into the component category ID field to correspond to the association between this component attribute information and the corresponding continuous beam component category; (4) Writing the function expression: Write the extracted function expression X≤15 into the function expression field as the calculation expression for the validation attribute value; (5) Function expression type writing: The type of the expression is determined based on the function expression. If the input value is a real number, 1 is written into the attribute validation type field. Different validation types have different logic in the subsequent validation logic algorithm, so it is recorded when entering the database. (6) The creation time of the component category is automatically obtained by the database function CURRENT_TIMESTAMP and written into the creation time field to record the writing time of this attribute data.

[0063] This embodiment includes, but is not limited to, the rules extracted from cross-sectional dimension compliance and floor slab thickness restrictions being entered into the database. Component data extracted from other specifications are also entered into the database through step S32.

[0064] This design constructs a standard type for rule validation, namely a four-level attribute structure tree relationship of "parent component - child component - attribute - expression", which facilitates the subsequent implementation of validation algorithm logic.

[0065] S4. BIM Model Data Preprocessing: Create a BIM model attribute data preprocessor. The BIM model attribute data preprocessor repackages the acquired BIM model attribute data to output a format consistent with the constructed component attribute tree structure.

[0066] Step S4 specifically includes: S41. Retrieve the JSON data of the BIM model components to be verified, and analyze and extract the JSON data. In this embodiment, taking the BIM model designed by OBD as an example, the original JSON data of the BIM model component attributes obtained is shown in Table 6 below: Table 6. Raw JSON data of BIM model component attributes

[0067] Analysis revealed that the root node in the original data represents the parent component category, the label value corresponding to the leaf node is the component attribute value, and the judgment logic for the leaf node is that if the children are empty, then the node is a leaf node of this component tree.

[0068] S42. Based on the analysis and extraction of JSON data in step S41, the original component data is extracted, the structure is reassembled, and the original JSON data is written into the "parent component-child component-attribute-attribute value" data structure. The purpose is to compare the "parent component-child component-attribute-attribute value" extracted from the BIM model with the "parent component-child component-attribute-expression" extracted and constructed from the industry standard described in step S3.

[0069] In this embodiment, an array object is created to store the assembled component attribute structure. The BIM model component information is traversed, the component attribute information is assigned to the new object array, and then output. The specific implementation process is as follows: (1) Create a component object CompareClassData, as shown in Table 7.

[0070] Table 7 Component Objects

[0071] (2) The attribute object CompareAttributeData is shown in Table 8.

[0072] Table 8 Attribute Objects

[0073] (3) Create an array List <compareclassdata>compareClassDataList = new ArrayList<>(); Based on the raw data obtained in step S41, determine whether the object is the last level of the component category by checking if the child attribute value is empty. If child is not empty, continue recursively traversing until child is empty, then assign the attribute name and attribute value to the leaf node of the last level; The execution result data of this method is shown in Table 9: Table 9 Results of Extracting Raw JSON Data

[0074] At this point, the BIM model attribute data preprocessor is complete. This embodiment takes the original OBD data format as an example. All data formats, including but not limited to this data format, are converted using this logic.

[0075] S5. Perform intelligent verification: Initiate a BIM model verification task, compare the pre-processed BIM model attribute data with the data in the verification rule table, and then record and store the verification results in the database.

[0076] Step S5 specifically includes: S51. Initiate a BIM model verification task and enter the task database as a record of the initiated verification task. This task will allow you to trace the entire verification process and results. The specific implementation process is as follows: (1) Write the verification task. Generate the verification task ID through the IdUtil.getSnowflake() method of the Hutool component to ensure global uniqueness and store it in the primary key ID field of the verification task; (2) Write the rule ID: Obtain the rule ID that performs this verification and write it into the rule ID field. (3) Write the task status. When the task status is "start verification", write 0 into the verification status field. (4) The creation time of the verification task is automatically obtained by the database function CURRENT_TIMESTAMP and written into the creation time field to record the writing time of the verification task and provide data support for subsequent processing.

[0077] S52. After initializing the task data and storing it in the database, the BIM model attribute verification begins. The pre-processed BIM model component information is compared and verified against the rule template data in the selected verification rule table, checking component classification, component attribute names, and attribute values. The specific implementation process is as follows: (1) Define two empty map objects to store the assembled model component information and rule template information respectively.

[0078] (2) Store the model component information data in Map<String,Object> In `modelMap = new HashMap<>()`, the key-value pairs of model components are recursively assembled, where the component category and attribute are the key, and the attribute value is the value. The attribute value name of the component is appended to the key, and the attribute value is assigned to the value. If the attribute value of the model is null, the attribute value is set to an empty string.

[0079] (3) Store the rule template data in a Map<String,Object> In `ruleMap = new HashMap<>()`, the key-value categories of the attached rules are recursively retrieved, with the key being the attribute and the value being the expression of the attribute. The attribute value name of the component is concatenated to the key, and the attribute expression is assigned to the value. The expression type is assigned to the value of the inner map, with the first-level value as the key and the expression type as the value of the inner map.

[0080] (4) Compare the results obtained from the two maps and define a List. <object>`modelKeyList = new ArrayList<>();` stores missing component category data. If the `modelMap` does not contain the component category specified in `ruleMap`, the specified component category is stored in `modelKeyList`, carrying the missing component category information. If the `modelMap` does not contain the component attribute specified in `ruleMap`, the component attribute is also stored in `modelKeyList`, carrying the missing component attribute information.

[0081] (5) For data whose component classification and component attributes both match, perform attribute value validation and obtain the corresponding expression map. The key is the expression and the value is the expression type. If the value obtained through the component rules is not null, the attribute of the component needs to be validated; otherwise, it is not validated.

[0082] (6) If the expression is not empty and the model attribute value is not empty, then the expression is calculated and the parameters are passed in for expression calculation.

[0083] (7) Determine if the attribute value is a real number. If it is a real number, calculate the function expression using the MVEL.eval() method and cast the result to a boolean value to obtain whether the attribute value is true.

[0084] (8) If the attribute value is a text type, the string is first split according to the || operator. If the subexpression contains the && operator, the value of the left operand is calculated first. If the value of the left operand is true, the value of the right operand will be calculated. Otherwise, the value of the entire subexpression is false.

[0085] (9) If the subexpression does not contain the && operator, the value of the subexpression is calculated directly. Since there is no && operator, there is no right operand. Here, the value of the right operand is set to true by default, and the value of the entire expression is updated according to the values ​​of the left and right operands.

[0086] S53. After the verification is completed, record the verification results and store them in the database for subsequent viewing and analysis, so as to realize the self-correction and calibration of the rules.

[0087] This embodiment stores the results of the end-to-end verification of each component attribute into the database, records the verification results, and writes them into the verification result table. The specific implementation is as follows: (1) Write each component attribute to be verified as a result data and write the verification result into the verification result field; (2) Write the reason for the failure of each component attribute verification into the specific reason field of the verification result to prepare basic data for self-calibration of subsequent analysis results; (3) Write the task ID that initiated this task into the task ID field of each data entry so that the task corresponding to the verification result can be traced later.

[0088] S6. Rule self-correction mechanism: Analyze and statistically analyze the verification results, automatically correct and calibrate verification rules that exceed the preset threshold, and mark the correction status, thereby realizing dynamic optimization of rules.

[0089] Step S6 specifically includes: S61. Analyze the obtained verification results and perform statistics on the verification results. Calculate the verification failure rate of each component for the eight types of result sets: missing parent component, incorrect parent component name, missing child component, incorrect child component name, missing component attribute, incorrect component attribute name, missing component attribute value, and incorrect component attribute value. S62. If the failure rate of the corresponding attribute value under a certain component exceeds the preset threshold, the function expression under the attribute of this component will be automatically corrected and calibrated. S63. Update the database for the revised rules and mark the revision status.

[0090] The following is a detailed implementation process of this embodiment: (1) Set a threshold for performing self-correction. In this embodiment, the threshold is set to 90%.

[0091] (2) Query the verification result table by the task ID. All the data corresponding to the task ID is the result set of this verification task. Store this result set in an array for the purpose of statistical analysis of the verification results.

[0092] (3) By analyzing the specific reasons field of the verification results of the result dataset, the result dataset is divided into eight categories: missing parent component, incorrect parent component name, missing child component, incorrect child component name, missing component attribute, incorrect component attribute name, missing component attribute value, and incorrect component attribute value.

[0093] (4) Calculate the failure rate of each component for the above eight result sets. If the failure rate of the attribute value under a certain component is greater than or equal to 90%, the function expression under this component attribute needs to be corrected and calibrated.

[0094] (5) Taking the minimum thickness of the two-way slab in the floor as an example, the original data attribute value of this result record is 78mm. After analyzing the verification results, the failure rate of this attribute value is greater than 90%. Therefore, it is necessary to correct the function expression under the corresponding rule. The standard for correction is that the minimum range value of the function is the original value of this component attribute. Therefore, the corrected function expression is X≥78mm.

[0095] (6) Update the database for the corrected rule, update the function expression field of the attribute structure table by verifying the id corresponding to the component attribute, modify the calibration flag field in the attribute structure table to 1, indicating that the attribute of this rule has been corrected, and record the current correction time in the update time field.

[0096] The above are the correction methods for the type of component attribute value error. The correction methods for the other seven types can be obtained by following the same steps. Example 2:

[0097] This embodiment discloses an intelligent BIM model review rule base system with self-correction function, including: The data storage module is configured to store the verification rule table, component classification table, attribute structure table, verification task table, and verification result table, and to establish a full-link data relationship of "verification rule - component classification - attribute - verification task - verification result". The rule standard construction module is configured to build rule standards based on industry specifications and for different engineering scenarios, and then store the rule standards in the validation rule table; The component attribute tree construction module is configured to extract parent category components, child category components, component attribute names, and attribute value constraint expressions from industry standards, construct the "parent component-child component-attribute-expression" attribute tree structure relationship of the BIM model, encapsulate it into a standardized component rule verification template, and store it in the database. The BIM model data preprocessing module is configured to create a BIM model attribute data preprocessor. The BIM model attribute data preprocessor repackages the acquired BIM model attribute data to output a format consistent with the constructed component attribute tree structure. The intelligent verification execution module is configured to initiate BIM model verification tasks, compare the pre-processed BIM model attribute data with the data in the verification rule table, and then record and store the verification results in the database. The rule self-correction module is configured to analyze and statistically process the verification results, automatically correct and calibrate verification rules that exceed preset thresholds, and mark the correction status, thereby achieving dynamic optimization of the rules.

[0098] The specific implementation process of the functions and roles of each module in the above system can be found in the implementation process of the corresponding steps in the method described in Embodiment 1, and will not be repeated here. For the system embodiment, since it basically corresponds to the method embodiment, relevant parts can be referred to in the description of the method embodiment.

[0099] The above description only outlines the basic principles and preferred embodiments of the present invention. Those skilled in the art can make many changes and modifications based on the above description, and these changes and modifications should fall within the protection scope of the present invention.< / object> < / compareclassdata>

Claims

1. A method for a self-correcting intelligent BIM model review rule base, characterized in that, include: Construct a data storage structure: Design a verification rule table, a component classification table, an attribute structure table, a verification task table, and a verification result table, and establish a full-link data relationship of "verification rule - component classification - attribute - verification task - verification result"; Build and store the rule standards: Build rule standards based on industry specifications and for different engineering scenarios, and then store the rule standards in the validation rule table; Constructing and storing component attribute trees: Extract parent-level categorized components, child-level categorized components, component attribute names, and attribute value constraint expressions from industry standards; construct the "parent component-child component-attribute-expression" attribute tree structure relationship of the BIM model; encapsulate it into a standardized component rule verification template; and store it in the database. BIM model data preprocessing: Create a BIM model attribute data preprocessor, which repackages the acquired BIM model attribute data to output a format consistent with the constructed component attribute tree structure. Perform intelligent verification: Initiate a BIM model verification task, compare the pre-processed BIM model attribute data with the data in the verification rule table, and then record and store the verification results in the database. Rule self-correction mechanism: Analyze and statistically analyze the verification results, automatically correct and calibrate verification rules that exceed the preset threshold and mark the correction status, thereby realizing dynamic optimization of rules.

2. The method for a self-correcting intelligent BIM model review rule base according to claim 1, characterized in that, The validation rule table is used to store imported initial rule data and custom rule data; the fields included in the validation rule table are rule primary key id, rule name, rule description, creator, creation time, updater, update time, and deletion status; The component classification table is used to enter the specified component classification data and match whether the BIM model components to be verified meet the classification standards. The component classification table includes the following fields: component classification primary key id, rule id, parent classification id, classification name, calibration flag, creator, creation time, updater, update time, and deletion status. The attribute structure table is used to enter the specified component attribute data, determine the attribute validation type, and match the component attribute names; The attribute structure table contains the following fields: attribute primary key id, component category id, attribute name, attribute validation type, function expression, calibration flag, creator, creation time, updater, update time, and deletion status. The verification task table is used to record information related to the rule verification task after it is initiated, as well as the execution status of the task. The fields included in the verification task table are: primary key id of the verification task, id of the rule to which it belongs, verification status, creator, creation time, and task completion time. The verification result table is used to record the result information after the verification task is completed. The fields included in the verification result table are: task ID, ID corresponding to the verification component attribute, ID corresponding to the verification component category, verification result, original data record of component attribute, and specific reason for verification result.

3. The method for a self-correcting intelligent BIM model review rule base according to claim 1, characterized in that, Establish a complete data relationship from "verification rules - component classification - attributes - verification tasks - verification results", including the following: The entire data relationship is linked by primary keys, constructing a closed-loop logic from "validation rule definition" to "validation result output". The specific relationships between each link are as follows: Association between validation rules and component categories: The component category table uses the primary key id of the validation rule table as a foreign key, and all component categories belonging to the same rule are uniformly linked to the corresponding rule, realizing the association logic of "one rule corresponds to several component categories"; Association between component categories and attributes: The attribute structure table uses the primary key id of the component category table as a foreign key to bind each attribute to the component category of the attribute, forming a hierarchical relationship of "one component category corresponds to several attributes"; Association between verification rules and verification tasks: When initiating a verification task, the primary key id of the target verification rule table must be specified so that each verification task is associated with a specific verification rule, clarifying the verification basis of the task and realizing the business logic of "one verification rule initiates several verification tasks". Association between verification tasks and verification results: The verification result table uses the primary key id of the verification task table as a foreign key to bind the verification results generated by each verification task to the verification task itself, forming a mapping relationship of "one verification task corresponds to several verification results".

4. The method for a self-correcting intelligent BIM model review rule base according to claim 2, characterized in that, The rules and standards are constructed and stored in the database, specifically including: (1) Define rule metadata: Rule Name: Define a rule name for the required engineering scenario, which will be used for subsequent display on the UI and user selection; Rule Description: Include a text description explaining the basis, purpose, and content of the established rule standard; (2) Standard rules are entered into the database: Generate a unique identifier: Generate a globally unique verification rule ID and store the verification rule ID in the primary key field id of the verification rule table, as the unique identity of this rule in the system; Write core information: Store the defined rule name in the rule name field and the rule description in the rule description field; (3) Record management information: Creation time: The current time is automatically obtained through a database function and stored in the creation time field; Status Management: Set the value of the delete status field to indicate whether the data for this rule is available.

5. The method for a self-correcting intelligent BIM model review rule base according to claim 1, characterized in that, Constructing the component attribute tree and storing it in the database includes: Extract parent-level category components, child-level category components, component attribute names, and attribute value constraint expressions from industry rules and standards to form a four-level attribute tree structure relationship of "parent component-child component-attribute-expression" in the BIM model, and encapsulate it into a standardized component rule verification template; The extracted parent and child components are stored in a component category table, and the attributes and expressions are stored in an attribute structure table. Furthermore, the relationships between the data are established, as follows: The relationship between parent and child components: Within the component category table, self-associations are established through the parent category id field. Each component category has one record in the component category table and a unique primary key id. When a component is a child of another component, the parent category id field of the child record is set to the id of its parent component record. The parent category id of the top-level parent structure is set to empty to identify it as the root node. The relationship between components and attributes: In the component attribute table, the component category id field is linked to the primary key id of the component category table. Each record in the component attribute table represents a specific attribute, and each attribute belongs to a component category. Therefore, the component category id field of the attribute record is set as the primary key id of the attribute component category in the component category table, establishing a one-to-many relationship of "one component category has multiple attributes".

6. The method for a self-correcting intelligent BIM model review rule base according to claim 1, characterized in that, BIM model data preprocessing specifically includes: Extract the JSON data of the BIM model components to be verified, and analyze and extract the JSON data; Based on the analysis and extraction of JSON data, the original component data is extracted, the structure is reassembled, and the original JSON data is written into the "parent component-child component-attribute-attribute value" data structure.

7. The method for a self-correcting intelligent BIM model review rule base according to claim 1, characterized in that, Performing intelligent verification specifically includes: Initiate a BIM model verification task and enter it into the task database as a record of the initiating verification task. After the initial task data is entered into the database, the BIM model attribute verification begins. The preprocessed BIM model component information is compared and verified with the rule template data in the selected verification rule table by component classification, component attribute name, and attribute value. After the verification is completed, the verification results are recorded and stored in the database for future viewing and analysis.

8. The method for a self-correcting intelligent BIM model review rule base according to claim 1, characterized in that, The rule self-correction mechanism specifically includes: The obtained verification results are analyzed and statistically analyzed. The verification failure rate of each component is calculated for eight categories of result sets: missing parent component, incorrect parent component name, missing child component, incorrect child component name, missing component attribute, incorrect component attribute name, missing component attribute value, and incorrect component attribute value. If the failure rate of the corresponding attribute value under a certain component exceeds the preset threshold, the function expression under the corresponding attribute of this component will be automatically corrected and calibrated. Update the database with the revised rules and mark the revision status.

9. A smart BIM model review rule base system with self-correction function, characterized in that, include: The data storage module is configured to store the verification rule table, component classification table, attribute structure table, verification task table, and verification result table, and to establish a full-link data relationship of "verification rule - component classification - attribute - verification task - verification result". The rule standard construction module is configured to build rule standards based on industry specifications and for different engineering scenarios, and then store the rule standards in the validation rule table; The component attribute tree construction module is configured to extract parent category components, child category components, component attribute names, and attribute value constraint expressions from industry standards, construct the "parent component-child component-attribute-expression" attribute tree structure relationship of the BIM model, encapsulate it into a standardized component rule verification template, and store it in the database. The BIM model data preprocessing module is configured to create a BIM model attribute data preprocessor. The BIM model attribute data preprocessor repackages the acquired BIM model attribute data to output a format consistent with the constructed component attribute tree structure. The intelligent verification execution module is configured to initiate BIM model verification tasks, compare the pre-processed BIM model attribute data with the data in the verification rule table, and then record and store the verification results in the database. The rule self-correction module is configured to analyze and statistically process the verification results, automatically correct and calibrate verification rules that exceed preset thresholds, and mark the correction status, thereby achieving dynamic optimization of the rules.

Images