An engineering building BIM data security management method

Abstract

The application discloses an engineering building BIM data security management method, comprising the following steps: step one: embedding a permission parameter into BIM model metadata through an attribute-based encryption algorithm; step two: deploying a permission management smart contract on a consortium chain, when a project management triggers a phase change event, the smart contract automatically calls the permission matrix generated in step one, calls a BIMBase platform API to obtain the latest model version, recalculates the permission matrix, verifies the identity of an operation party, and distributes the encrypted new permission set to relevant nodes; step three: building a three-party consortium chain audit module and adopting an improved PBFT consensus algorithm to perform audit confirmation within 5 seconds; developing a BIM event log visualization interface, and supporting multi-dimensional retrieval according to roles, time and operation types; and step four: building an abnormality detection module of an LSTM-CNN hybrid model; building a normal behavior baseline model through transfer learning; when it is detected that an operation deviates from the baseline for three times in succession, the module automatically triggers a three-level response mechanism.

Description

Technical Field

[0001] This invention relates to the field of data security management technology, and in particular to a method for managing the security of BIM data in engineering construction. Background Technology

[0002] Since its emergence in the early 21st century, Building Information Modeling (BIM) technology has become a core tool for the digital transformation of the global construction industry. By integrating information throughout the entire lifecycle of a building through a three-dimensional digital model, it enables collaborative work across the design, construction, and operation and maintenance stages, significantly improving project efficiency and reducing error rates.

[0003] However, with the deepening application of BIM, the massive amounts of multi-source heterogeneous data it generates involve multiple parties such as owners, design institutes, general contractors, and subcontractors, and the problem of uncontrolled collaborative operation permissions is becoming increasingly prominent. Taking a large commercial complex project as an example: after the project adopted the BIM collaborative platform, each team needed to update the model data in real time. However, due to the coarse permission settings, an engineer from a subcontractor accidentally deleted the parameter information of key components of the main structure, which led to a conflict between the subsequent rebar binding construction and the model, resulting in rework. At the same time, the owner's representative modified the elevation of the MEP pipelines without authorization, causing professional clashes. The static permission allocation based on roles is difficult to adapt to the dynamic collaboration scenario of BIM, resulting in the coexistence of "unauthorized operation" and "lack of operation traces". Therefore, a method for BIM data security management in engineering construction is proposed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method for secure management of BIM data in engineering construction.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] A method for secure management of BIM data in engineering construction includes:

[0007] Step 1: Construct a three-dimensional permission matrix, which quantitatively binds the role attributes, temporal attributes (such as design stage and construction stage), and spatial attributes (such as floor and area) of design, construction, and supervision. Through attribute-based encryption algorithms, permission parameters are embedded into the BIM model metadata to build a dynamic association between model, role, and stage. For example, structural engineers in the construction stage can only modify the reinforcement parameters of the current construction section and cannot access historical data of the accepted areas.

[0008] Step 2: Deploy a permission management smart contract on the consortium blockchain and preset a permission change rule base. For example, when the construction progress reaches 30%, the electromechanical installation permission will be activated. When the project management triggers a phase change event, such as when the concrete pouring is completed, the smart contract will automatically perform the following operations: call the BIMBase platform API to obtain the latest model version, recalculate the permission matrix according to the rules, verify the identity of the operator through zero-knowledge proof, and finally distribute the encrypted new permission set to the relevant nodes.

[0009] Step 3: Construct a three-party consortium blockchain audit module that includes the construction unit, the contractor, and the regulatory agency. The module generates a hash value containing timestamp, operation type, and model version for each BIM operation, and uses an improved PBFT consensus algorithm to confirm the audit within 5 seconds; develop a BIM event log visualization interface that supports multi-dimensional retrieval by role, time, and operation type, and enables full traceability of the operation process;

[0010] Step 4: Construct an anomaly detection module for the LSTM-CNN hybrid model; First, extract operation sequence features (such as the time interval between opening, modifying, and saving the model) from the BIM event log, and construct a baseline model for normal behavior through transfer learning; When three consecutive operations deviating from the baseline are detected (such as modifying core parameters outside of working hours), the module automatically triggers a three-level response mechanism: rollback of the model version, sending a warning notification containing operation video to the supervisor, and initiating secondary facial recognition authentication.

[0011] The above technical solution further includes:

[0012] Furthermore, the construction of the three-dimensional permission matrix, which quantifies and binds role attributes, temporal attributes, and spatial attributes, includes the following steps:

[0013] Define category attributes:

[0014] The role attributes clearly define the role types of the parties involved in collaborative work, including the designer, the construction party, the supervisor, and the owner, and define basic permission levels for each role (e.g., the designer has the right to modify the model, while the construction party only has the right to view parameters); assign unique identifiers to roles (such as "Design-001" and "Construction-002"), and associate them with permission tags ("Modify", "View", "Approve").

[0015] Time-series attributes: The project lifecycle is divided into stages including design, construction, and operation and maintenance, and permission access rules for each stage are defined. For example, during the construction stage, only the model parameters of the current construction segment can be modified; the project progress percentage is mapped to time-series labels (such as "Construction 30%" and "Construction 60%), and the permission scope is dynamically adjusted.

[0016] Spatial attributes: The BIM model is broken down into hierarchical spatial units (project → building → floor → component), and operation permissions are defined for each unit. For example, structural engineers can only modify the component parameters at the "main structure" level. A unique ID is assigned to each spatial unit (such as "floor-01" and "component-003"), and operation restrictions are associated with them, such as "only allow adjustment of rebar diameter".

[0017] Quantization binding of three-dimensional properties:

[0018] Create a 3D table where rows represent role attributes, columns represent temporal attributes, and depth represents spatial attributes, forming a three-dimensional permission model of role × temporal × spatial. For example, the designer (role) has full modification rights to the main structure (space) during the design phase (temporal), but only retains parameter viewing rights during the construction phase (temporal). Define the linkage logic between attributes, for example:

[0019] Temporal-spatial linkage: When the construction progress reaches 50%, modification permissions for the "secondary structure" level are automatically granted;

[0020] Role-space linkage: The construction team can only operate the components of the current construction section and is prohibited from modifying them across areas;

[0021] Timing-role linkage: During the operation and maintenance phase, only the owner is allowed to adjust equipment parameters, and the permissions of other roles are frozen;

[0022] The quantified permission matrix is ​​converted into an encrypted policy file, and the policy is embedded into the BIM model metadata (such as attribute fields in IFC format) using the ABE algorithm; this ensures that the model file carries dynamic permission information and enables real-time binding of model-role-stage (e.g., automatically identifying the operator role and current stage when the model is opened, and loading the corresponding permissions).

[0023] Validation optimization:

[0024] Select typical collaborative work scenarios (such as design changes and construction briefings) to verify whether the permission matrix restricts operations as expected. For example, the construction party is denied permission when attempting to modify parameters outside the current construction section. Check for logical contradictions in attribute binding (such as role A having the right to modify space C in phase B, but phase C prohibiting operations on space C). Resolve conflicts by adjusting quantitative parameters (modifying time series labels or space IDs). Set update trigger conditions for the permission matrix (such as project phase changes or the addition of new roles) to ensure that the matrix can adapt to project progress. For example, after entering the operation and maintenance phase, automatically tighten the permissions of the design party and open the permissions of the owner party.

[0025] Furthermore, the dynamic association between the model, roles, and stages is constructed by including the following steps:

[0026] Model structured decomposition:

[0027] The BIM model is broken down into hierarchical units based on physical structure or functional modules (e.g., project → building → floor → component → parameter). For example:

[0028] First-level unit: the entire project, such as "a certain commercial complex";

[0029] Secondary unit: Individual building, such as "Office Building #1" and "Residential Building #2";

[0030] Third-level unit: floor or functional area, such as "Office Building 1 - 5th floor" or "Residential Building 2 - basement";

[0031] Level 4 unit: specific components and parameters, such as "5th floor beam and column components" and "basement fire pipe diameter";

[0032] Assign a unique identifier to each model unit (such as “component-001”, “parameter-002”) to enable precise location and access control of the model structure;

[0033] Define role permissions:

[0034] List all roles involved in the collaborative work, including the designer, construction company, supervisor, and owner, and define their core responsibilities:

[0035] The design team is responsible for creating and modifying the model.

[0036] The construction company is responsible for adjusting and verifying parameters during the construction phase.

[0037] Supervisory party: Responsible for reviewing operational compliance;

[0038] Owner: Responsible for final approval and adjustments during the operation and maintenance phase;

[0039] Set basic permission scopes for each role, such as "modify", "view", "approval" and "freeze". For example, the designer has "modify" permission by default, which is limited to the design stage; the construction team has "view" permission by default, which can be upgraded to "adjust" during the construction stage.

[0040] Project phases:

[0041] The project lifecycle is divided into phases (e.g., design, construction, and operation / maintenance), and milestone events for phase transitions are set (e.g., "construction drawings approved" or "main structure topped out"). The access control logic for each phase is defined, for example:

[0042] Design phase: The design team has the right to modify all components of the model, while other roles are only allowed to view them;

[0043] During the construction phase: the construction party gains the right to adjust the components of the current construction section, while the design party's authority is reduced to "parameter verification";

[0044] During the operation and maintenance phase: The owner gains the right to modify the equipment parameters, while the permissions of other roles are frozen.

[0045] Dynamic correlation of three elements:

[0046] Establish a three-dimensional mapping table of "model unit-role-stage" to clarify the operation permissions of different roles for different units of the model at different stages, for example:

[0047] Example of a rule: Construction stage (stage) → Construction party (role) → Beam and column components of the current construction section (model element) → Allow adjustment of rebar diameter (operation permission);

[0048] Define the trigger conditions for the association rule to take effect, for example:

[0049] Phase change trigger: When the project progress reaches 50%, modification permissions for the "secondary structure" level are automatically granted;

[0050] Role addition trigger: When a new construction team enters the site, the permission template for its corresponding construction section is automatically loaded;

[0051] Model update trigger: After the designer submits a model change, the construction party's right to modify the relevant components is automatically frozen, and the right to be unfrozen is required to be approved by the supervisor.

[0052] Furthermore, the permission management smart contract includes the following:

[0053] Embed a set of conditional action rules for permission changes in the contract, for example:

[0054] Example rule 1: When the project phase changes from "design phase" to "construction phase", the designer's right to modify the components of the construction phase is automatically revoked;

[0055] Example Rule 2: When the construction party completes the concrete pouring of a certain floor (triggered by the PM system), grant them the right to adjust the electromechanical installation of the next floor.

[0056] Before the contract is deployed, it must be jointly signed by the construction unit, the construction contractor, and the regulatory agency to ensure that the rules meet the actual needs of the project and that there is no possibility of unilateral alteration.

[0057] Event-triggered execution:

[0058] The smart contract continuously listens for events pushed by the project management module, such as stage change events (e.g., "construction progress reaches 30%)", role addition / exit events (e.g., a new construction party enters the site), and model update events (e.g., the designer submits a new version of the BIM model).

[0059] When an event is triggered, the contract automatically matches the corresponding conditions in the rule base. For example, the event is: Construction progress reaches 50% → matching rule: "When the construction phase reaches 50%, grant permission to modify secondary structures". The action is to calculate the role (such as the construction party) and model unit (such as the secondary structure wall) whose permissions need to be adjusted. Before executing the permission change, the contract requires the operator to verify their identity through zero-knowledge proof. For example, the construction party needs to prove that it belongs to the project's authorized construction team, but does not need to disclose specific personnel information; the supervisor needs to prove that it has the qualifications for compliance review, but does not need to disclose personal privacy data.

[0060] Permission changes are executed and logs are generated:

[0061] Based on the rule matching results, the contract dynamically generates a new set of permissions. For example, it may revoke the designer's "modify" permission for components in the construction section, but retain the "view" permission; and grant the contractor "adjust" permission for the electromechanical equipment in the current construction section, limiting the scope of adjustment, such as allowing only ±5% modification of the pipe diameter.

[0062] The encrypted new permission set is broadcast to relevant nodes on the client side, such as the design and construction parties, via the blockchain and synchronized to the BIM model metadata. The "model-permission" binding is performed through ABE encryption in step one.

[0063] The contract automatically generates log entries containing timestamps, operation types, model versions, and the operator's digital certificate, such as "2025-07-25 14:30, the construction party (digital certificate ID: SP-001) triggered a 50% permission adjustment during the construction phase, and the new permission set has been distributed."

[0064] Linking with other steps:

[0065] When the contract is executed, the permission matrix generated in step one is invoked to ensure that permission changes comply with the dynamic association rules of model-role-stage, such as not exceeding spatial attribute restrictions; the operation log is synchronized to the third-party consortium blockchain audit module in real time (step three) to provide raw data for subsequent audits (such as the supervisor can trace whether permission changes are compliant through the logs).

[0066] Furthermore, the step of recalculating the permission matrix according to the rules and verifying the identity of the operator through zero-knowledge proof includes the following steps:

[0067] Event triggered:

[0068] When the project management module detects a phase change, such as the construction progress reaching 50%, it pushes an event notification to the smart contract, stating that "the construction phase has entered the second phase of the project." The smart contract matches the corresponding conditions in the preset rule base according to the event type (phase change), for example: "When the construction phase reaches 50%, grant the construction party the right to adjust the components of the second phase of the project, and at the same time revoke the design party's right to modify the area."

[0069] Dynamically recalculate the permission matrix:

[0070] The smart contract obtains the currently effective three-dimensional permission matrix (role-time sequence-spatial attribute) from step one. For example, the designer has the right to modify the "main structure" level in the early stage of construction.

[0071] Based on the event trigger condition (50% construction progress), the permission matrix is ​​dynamically adjusted:

[0072] Access granted: The construction party obtains the right to adjust the "Phase II Project Components" (spatial attribute binding);

[0073] Restricted access: The designer's right to modify "Phase II project components" is frozen (time-sequence attribute binding).

[0074] The adjusted permission matrix is ​​converted into a new permission set in encrypted format. For example, the construction party (role) has "adjustment" permission for the second-phase components (space) for 50% (time sequence) of the construction phase; the design party (role) has "no" permission for the second-phase components (space) for 50% (time sequence) of the construction phase.

[0075] Zero-knowledge proof authentication:

[0076] When the construction party needs to perform an adjustment operation, its client sends a request to the smart contract, along with a digital certificate, such as "Construction Party-SP-001". The smart contract generates a random challenge value ("random number-123"), requiring the operator to prove its identity legitimacy through zero-knowledge proof, for example: proof objective: "I am an authorized construction party for the project, and my digital certificate has not been revoked". The construction party's client generates a ZKP proof based on the challenge value and its private key, and submits it to the smart contract, for example, proof content: "I possess a private key that matches digital certificate SP-001, and the certificate status is valid". The smart contract checks the validity of the proof through the ZKP verification algorithm to ensure that the operator does indeed possess the private key of the corresponding digital certificate, and that the certificate has not been revoked or expired, and queries the certificate status through the blockchain.

[0077] Permission change:

[0078] If ZKP verification is successful, the smart contract will distribute the encrypted new permission set to the relevant nodes (such as the construction party's client) and synchronize it to the BIM model metadata (the "model-permission" binding is achieved through ABE encryption in step one). If verification fails, such as when the operator cannot provide valid proof, the contract will reject the permission change request and record the abnormal event (such as "Construction party-SP-002 attempted to illegally obtain the right to adjust the second phase components"). Regardless of whether the verification is successful or not, the contract will generate a log entry containing a timestamp, operation type, model version, and operator's digital certificate, and push it to the audit module in step three.

[0079] Dynamic association:

[0080] Permission adjustments rely on identity verification. The generation of new permission sets (such as granting construction parties the right to adjust permissions) requires the operator to be legitimate to avoid unauthorized operations. Identity verification ensures permission security, and zero-knowledge proofs ensure that only authorized roles can trigger permission changes, thus solving the subjective vulnerabilities of traditional manual review. A closed-loop linkage forms a security barrier: stage change → permission recalculation → identity verification → permission execution → log auditing, forming a complete chain of "event-driven - permission adjustment - security verification - result traceability".

[0081] Furthermore, the construction of the three-party consortium blockchain audit module, which includes the construction unit, the contractor, and the regulatory agency, includes the following steps:

[0082] Initialize the consortium blockchain:

[0083] A consortium blockchain is jointly established by the construction company, the contractor, and the regulatory agency, with node permissions set:

[0084] Construction unit node: Has final approval authority and can query all audit logs;

[0085] Construction unit node: can only query logs related to its own operations (such as construction section component adjustment records);

[0086] Regulatory agency nodes: have full log query rights and can initiate compliance reviews;

[0087] The three parties complete node registration through digital certificates (such as “Construction-001” issued by the construction unit and “Construction-002” issued by the construction company), making their identities traceable.

[0088] Generate storage audit logs:

[0089] Each BIM operation generates a structured log entry:

[0090] Timestamp: The time when the operation occurred (accurate to the second);

[0091] Operation type: such as "Model Open", "Parameter Modification", "Permission Change";

[0092] Model version: The version number of the BIM model involved in the operation;

[0093] Operator identification: Digital certificate ID (e.g., “Design-001”, “Construction-002”);

[0094] Operation Summary: Briefly describe the operation object (e.g., "modify the diameter of the reinforcing bars in the beams and columns of the 5th floor").

[0095] Perform hash calculations on log entries to generate unique hash values, and store the hash values ​​on the blockchain to make the logs immutable;

[0096] Verification by multiple parties' consensus:

[0097] By employing an optimized PBFT (Practical Byzantine Fault Tolerance) algorithm, the consensus time is reduced to within 5 seconds:

[0098] Master node election: The master node is selected according to the rotation rules (such as the order of construction unit → construction unit → regulatory agency);

[0099] Log broadcasting: The master node broadcasts the newly generated log hash value to other nodes;

[0100] Voting verification: Each node verifies the hash value (e.g., checks whether the timestamp is valid and whether the operation type complies with permissions) and returns an "agree" or "reject" vote;

[0101] Consensus reached: When at least 2 / 3 of the nodes agree, the hash value is officially written into the blockchain, and audit confirmation is completed;

[0102] If a node has a dispute over the log content (such as a regulatory agency questioning the compliance of an operation), it can initiate a "dispute audit" process: lock the disputed log and suspend subsequent operations; the three parties review the original operation record through an offline meeting or encrypted channel; and update the log status (such as marking it as "compliant" or "non-compliant") after reaching an agreement.

[0103] Develop a visual audit interface:

[0104] Develop web or mobile interfaces that support querying logs by the following dimensions:

[0105] Role-based: Filter operation records for specific roles (such as construction parties);

[0106] Time dimension: Define a time range, such as "July 2025";

[0107] Operation type dimension: Focus on specific operations, such as "permission change";

[0108] Provides an operation sequence visualization function to display all the operations of a certain role within a specific time period, such as "Construction Party - SP-001 modified the diameter of the steel bars in the beam and column components on the 5th floor on July 20th";

[0109] De-identified data processing:

[0110] Extract the features needed for AI training from the audit logs, while removing sensitive information:

[0111] Retained features: operation time interval, operation type sequence, model version change frequency;

[0112] Removed features: operator's digital certificate ID, specific parameter value (specific value of rebar diameter);

[0113] Set a daily scheduled task at midnight to package the anonymized audit data (CSV format) and push it to the AI ​​training module in step four through a secure channel;

[0114] Furthermore, the anomaly detection module for constructing the LSTM-CNN hybrid model includes the following steps:

[0115] Data preprocessing:

[0116] The de-identified BIM event logs are received from the audit module in step three, including operation timestamps, operation type sequences (e.g., "model open - parameter modification - save"), and model version change records. Key features are retained: operation time intervals (e.g., whether the interval between two modification operations is abnormal); operation type sequences (e.g., "modifying core parameters outside of working hours"); and model version jumps (e.g., jumping directly from V1.0 to V3.0, skipping V2.0). Sensitive information such as the operator's digital certificate ID and specific parameter values ​​(e.g., the specific value of the rebar diameter) are removed. Normal operations are marked as "0", and abnormal operations (e.g., unauthorized modifications, operations outside of working hours) are marked as "1", forming a labeled training dataset.

[0117] Designing an LSTM-CNN hybrid model architecture:

[0118] The input layer receives preprocessed operation sequence data (shape: [time step, number of features]); the LSTM layer captures the temporal dependencies in the operation sequence, such as "save immediately after modifying parameters" is a normal mode, while "save the next day after modification" may be abnormal, processes time series features, and outputs the hidden state; the CNN layer extracts local combination features of operation types, such as "model open + parameter modification" is a normal combination, while "model open + permission change" may be abnormal, performs convolution operations on the hidden state output by the LSTM, and extracts local patterns; the merging layer concatenates the outputs of the LSTM and CNN, and inputs them into the fully connected layer for classification (normal / abnormal).

[0119] Training and optimizing the model:

[0120] Load the parameters of the LSTM-CNN model pre-trained in a similar engineering scenario (such as a subway construction project) to accelerate local training and improve initial accuracy; fine-tune the model using anonymized project data to optimize parameters to adapt to the current project's operational mode (e.g., adjust the number of hidden units in the LSTM and the kernel size of the CNN); divide the dataset into a training set (70%), a validation set (20%), and a test set (10%); adjust hyperparameters such as the learning rate and batch size using the validation set, and employ an early stopping mechanism to prevent overfitting (e.g., stop training if the loss does not decrease after 5 consecutive validation rounds).

[0121] Anomaly Detection and Response:

[0122] After a new operation log is generated, it is immediately input into the trained model, which outputs anomaly probability values. When the probability value exceeds a preset threshold and anomalies are detected three times consecutively, a three-level response mechanism is triggered:

[0123] Level 1 Response (Model Version Rollback):

[0124] Automatically roll back the BIM model to the previous normal version (e.g., roll back from V3.0 to V2.0) to ensure that construction continues to use the trusted model; link the smart contract in step two to freeze the permissions of the current operator (e.g., the adjustment right of the construction party-SP-001 is temporarily revoked).

[0125] Level II Response (Early Warning Notification):

[0126] Send an alert notification to the supervisor containing operation video clips, timestamps, and operation type (e.g., "2025-07-25 23:15, Construction Party - SP-001 attempted to modify core parameters"); the alert notification is sent through an encrypted channel, making the information visible only to the supervisor.

[0127] Level 3 Response (Secondary Authentication):

[0128] Initiate facial recognition or fingerprint recognition to require the operator to perform secondary authentication; if authentication fails, permanently freeze their permissions and mark them as a "high-risk operator";

[0129] Closed-loop optimization:

[0130] Detected abnormal events (such as "parameter modification outside of working hours") are fed back to Step 1. The permission matrix parameters are dynamically adjusted to add spatiotemporal constraints (such as "modification of core parameters is prohibited during the construction phase from 22:00 to 6:00"), and the role permission template is modified (such as restricting the adjustment range of specific components by the construction party). The model is incrementally trained monthly using the latest de-identified data to maintain the ability to identify emerging abnormal patterns (such as new unauthorized operation methods). The updated model must be deployed after consensus confirmation by the three-party consortium blockchain (Step 3) to ensure the credibility of the detection logic.

[0131] Furthermore, the abnormal event is fed back to step one to dynamically adjust the permission matrix parameters, including the following steps:

[0132] Feedback on abnormal events:

[0133] When the LSTM-CNN model in step four detects three consecutive deviations from the baseline, it is automatically marked as an "abnormal event requiring optimization"; a feedback packet containing details of the abnormal event is generated, including:

[0134] Exception types: such as "operation outside of working hours" and "unauthorized access";

[0135] Operator identification: Digital certificate ID (e.g., "Construction Party-SP-001");

[0136] Operation content: The specific components, parameters, or permissions to be modified, such as "modify the diameter of the steel bars in the beams and columns on the 5th floor";

[0137] Time of occurrence: A timestamp accurate to the second (e.g., "2025-07-25 23:15");

[0138] Analysis of the cause of the anomaly:

[0139] By combining the audit logs (Step 3) and the permission matrix (Step 1), analyze the cause of the anomaly:

[0140] Insufficient spatiotemporal constraints: The permission matrix does not restrict modifications to core parameters during non-working hours;

[0141] Excessive role permissions: The construction party was granted the right to adjust components beyond its construction section;

[0142] Phase mismatch error: The model version is out of sync with the project phase, causing errors in permission calculations;

[0143] Based on the root cause analysis results, the directions for optimizing the permission matrix are determined as follows:

[0144] Add spatiotemporal constraints: Bind a rule to the permission matrix that "modification of core parameters is prohibited outside of working hours";

[0145] Reduce role permissions: restrict the construction party's adjustment permissions to components of "current construction section + adjacent 1 floor";

[0146] Correct phase mapping: Ensure that the model version strictly corresponds to the project phase, such as the V2.0 model only taking effect when the construction phase is 50% complete;

[0147] Dynamically adjust permission matrix parameters:

[0148] Based on the adjustment objectives, modify the three-dimensional attribute binding rules of the permission matrix, for example:

[0149] Time attribute refinement: The "construction phase" is divided into "daytime (6:00-22:00)" and "nighttime (22:00-6:00)". Core parameters cannot be modified during the nighttime period;

[0150] Spatial attributes are tightened: the spatial permissions of the construction party are tightened from the "single building" level to the "floor + construction section" level (e.g., only the "1# office building - 5th floor - east section" component can be adjusted);

[0151] Role permission template optimization: Added "Parameter Review" permission for designers (can only view the construction party's modification records, cannot directly modify them);

[0152] After the adjustment, the system automatically checks the compatibility of the new rules with existing rules, for example:

[0153] Conflict detection: Ensure that the rule "prohibit modification of core parameters at night" does not conflict with the rule "modification is allowed during emergency repair periods";

[0154] Coverage verification: Confirm that the new rules cover all similar abnormal scenarios (such as modifying device parameters outside of working hours, or adjusting unauthorized components without authorization).

[0155] Verify the adjustment effect:

[0156] Simulate the adjusted permission matrix in a test environment to verify its control effect on typical scenarios, such as:

[0157] Scenario 1: The construction team attempts to modify core parameters at night → triggers an insufficient permissions warning;

[0158] Scenario 2: The designer attempts to modify components in an unauthorized construction section → triggering an unauthorized access warning;

[0159] After verification, the adjusted permission matrix will be synchronized to the dynamic permission modeling module in step one, and the encryption policy file will be regenerated (embedded with BIM model metadata through the ABE algorithm).

[0160] Continuous optimization:

[0161] Step 2 (Smart Contract): Receive the new permission matrix and update the condition-action rules in the rule base (e.g., "Construction parties are prohibited from modifying core parameters during nighttime"). Step 3 (Audit Module): Record permission matrix adjustment events and generate a comparison log containing before and after the adjustment (e.g., "2025-07-26 10:00, nighttime operation restrictions added to the permission matrix"). Step 4 (AI Model): Re-input the adjusted normal operation mode into the LSTM-CNN model and update the behavior baseline (e.g., "No core parameter modification at night" becomes the new baseline). Continuously monitor the effect of the adjusted permission matrix. If a similar anomaly is detected again (e.g., the construction party modifies parameters through other paths at night), a new round of feedback-adjustment loop is triggered, forming a continuous optimization mechanism of "detection-analysis-adjustment-verification".

[0162] The present invention has the following beneficial effects:

[0163] In this invention, a dynamic association between "model-role-stage" is achieved by constructing a three-dimensional permission matrix and an attribute-based encryption algorithm. A rule base is preset in the smart contract deployed on the consortium blockchain. When the stage changes, the BIMBase API is automatically called to recalculate permissions and verify identity through zero-knowledge proof. The encrypted permission set is distributed to nodes and the operation log is synchronized to the third-party consortium blockchain audit module. This module uses an improved PBFT algorithm to complete hash notarization within 5 seconds and combines an LSTM-CNN anomaly detection model to perform baseline learning on the operation sequence. When there are three consecutive deviations, a three-level response of version rollback, video warning, and face authentication is triggered. Finally, the permission matrix parameters are dynamically adjusted through anomaly feedback, effectively solving the problem of uncontrolled collaborative operation permissions in BIM collaboration, such as unauthorized operations, chains of misoperations, and difficulty in tracing responsibility. Attached Figure Description

[0164] Figure 1 This is a flowchart of a method for managing the security of BIM data in engineering construction proposed in this invention. Detailed Implementation

[0165] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0166] Please see Figure 1 As shown, this invention is a method for BIM data security management in engineering construction, comprising:

[0167] Step 1: Construct a three-dimensional permission matrix, which quantitatively binds the role attributes, temporal attributes (such as design stage and construction stage), and spatial attributes (such as floor and area) of design, construction, and supervision. Through attribute-based encryption algorithms, permission parameters are embedded into the BIM model metadata to build a dynamic association between model, role, and stage. For example, structural engineers in the construction stage can only modify the reinforcement parameters of the current construction section and cannot access historical data of the accepted areas.

[0168] Step 2: Deploy a permission management smart contract on the consortium blockchain and preset a permission change rule base. For example, when the construction progress reaches 30%, the electromechanical installation permission will be activated. When the project management triggers a phase change event, such as when the concrete pouring is completed, the smart contract will automatically perform the following operations: call the BIMBase platform API to obtain the latest model version, recalculate the permission matrix according to the rules, verify the identity of the operator through zero-knowledge proof, and finally distribute the encrypted new permission set to the relevant nodes.

[0169] Step 3: Construct a three-party consortium blockchain audit module that includes the construction unit, the contractor, and the regulatory agency. The module generates a hash value containing timestamp, operation type, and model version for each BIM operation, and uses an improved PBFT consensus algorithm to confirm the audit within 5 seconds; develop a BIM event log visualization interface that supports multi-dimensional retrieval by role, time, and operation type, and enables full traceability of the operation process;

[0170] Step 4: Construct an anomaly detection module for the LSTM-CNN hybrid model; First, extract operation sequence features (such as the time interval between opening, modifying, and saving the model) from the BIM event log, and construct a baseline model for normal behavior through transfer learning; When three consecutive operations deviating from the baseline are detected (such as modifying core parameters outside of working hours), the module automatically triggers a three-level response mechanism: rollback of the model version, sending a warning notification containing operation video to the supervisor, and initiating secondary facial recognition authentication.

[0171] In one embodiment, constructing a three-dimensional permission matrix and quantifying and binding role attributes, temporal attributes, and spatial attributes includes the following steps:

[0172] Define category attributes:

[0173] The role attributes clearly define the role types of the parties involved in collaborative work, including the designer, the construction party, the supervisor, and the owner, and define basic permission levels for each role (e.g., the designer has the right to modify the model, while the construction party only has the right to view parameters); assign unique identifiers to roles (such as "Design-001" and "Construction-002"), and associate them with permission tags ("Modify", "View", "Approve").

[0174] Time-series attributes: The project lifecycle is divided into stages including design, construction, and operation and maintenance, and permission access rules for each stage are defined. For example, during the construction stage, only the model parameters of the current construction segment can be modified; the project progress percentage is mapped to time-series labels (such as "Construction 30%" and "Construction 60%), and the permission scope is dynamically adjusted.

[0175] Spatial attributes: The BIM model is broken down into hierarchical spatial units (project → building → floor → component), and operation permissions are defined for each unit. For example, structural engineers can only modify the component parameters at the "main structure" level. A unique ID is assigned to each spatial unit (such as "floor-01" and "component-003"), and operation restrictions are associated with them, such as "only allow adjustment of rebar diameter".

[0176] Quantization binding of three-dimensional properties:

[0177] Create a 3D table where rows represent role attributes, columns represent temporal attributes, and depth represents spatial attributes, forming a three-dimensional permission model of role × temporal × spatial. For example, the designer (role) has full modification rights to the main structure (space) during the design phase (temporal), but only retains parameter viewing rights during the construction phase (temporal). Define the linkage logic between attributes, for example:

[0178] Temporal-spatial linkage: When the construction progress reaches 50%, modification permissions for the "secondary structure" level are automatically granted;

[0179] Role-space linkage: The construction team can only operate the components of the current construction section and is prohibited from modifying them across areas;

[0180] Timing-role linkage: During the operation and maintenance phase, only the owner is allowed to adjust equipment parameters, and the permissions of other roles are frozen;

[0181] The quantified permission matrix is ​​converted into an encrypted policy file, and the policy is embedded into the BIM model metadata (such as attribute fields in IFC format) using the ABE algorithm; this ensures that the model file carries dynamic permission information and enables real-time binding of model-role-stage (e.g., automatically identifying the operator role and current stage when the model is opened, and loading the corresponding permissions).

[0182] Validation optimization:

[0183] Select typical collaborative work scenarios (such as design changes and construction briefings) to verify whether the permission matrix restricts operations as expected. For example, the construction party is denied permission when attempting to modify parameters outside the current construction section. Check for logical contradictions in attribute binding (such as role A having the right to modify space C in phase B, but phase C prohibiting operations on space C). Resolve conflicts by adjusting quantitative parameters (modifying time series labels or space IDs). Set update trigger conditions for the permission matrix (such as project phase changes or the addition of new roles) to ensure that the matrix can adapt to project progress. For example, after entering the operation and maintenance phase, automatically tighten the permissions of the design party and open the permissions of the owner party.

[0184] In one embodiment, the dynamic association of the model-role-stage includes the following steps:

[0185] Model structured decomposition:

[0186] The BIM model is broken down into hierarchical units based on physical structure or functional modules (e.g., project → building → floor → component → parameter). For example:

[0187] First-level unit: the entire project, such as "a certain commercial complex";

[0188] Secondary unit: Individual building, such as "Office Building #1" and "Residential Building #2";

[0189] Third-level unit: floor or functional area, such as "Office Building 1 - 5th floor" or "Residential Building 2 - basement";

[0190] Level 4 unit: specific components and parameters, such as "5th floor beam and column components" and "basement fire pipe diameter";

[0191] Assign a unique identifier to each model unit (such as “component-001”, “parameter-002”) to enable precise location and access control of the model structure;

[0192] Define role permissions:

[0193] List all roles involved in the collaborative work, including the designer, construction company, supervisor, and owner, and define their core responsibilities:

[0194] The design team is responsible for creating and modifying the model.

[0195] The construction company is responsible for adjusting and verifying parameters during the construction phase.

[0196] Supervisory party: Responsible for reviewing operational compliance;

[0197] Owner: Responsible for final approval and adjustments during the operation and maintenance phase;

[0198] Set basic permission scopes for each role, such as "modify", "view", "approval" and "freeze". For example, the designer has "modify" permission by default, which is limited to the design stage; the construction team has "view" permission by default, which can be upgraded to "adjust" during the construction stage.

[0199] Project phases:

[0200] The project lifecycle is divided into phases (e.g., design, construction, and operation / maintenance), and milestone events for phase transitions are set (e.g., "construction drawings approved" or "main structure topped out"). The access control logic for each phase is defined, for example:

[0201] Design phase: The design team has the right to modify all components of the model, while other roles are only allowed to view them;

[0202] During the construction phase: the construction party gains the right to adjust the components of the current construction section, while the design party's authority is reduced to "parameter verification";

[0203] During the operation and maintenance phase: The owner gains the right to modify the equipment parameters, while the permissions of other roles are frozen.

[0204] Dynamic correlation of three elements:

[0205] Establish a three-dimensional mapping table of "model unit-role-stage" to clarify the operation permissions of different roles for different units of the model at different stages, for example:

[0206] Example of a rule: Construction stage (stage) → Construction party (role) → Beam and column components of the current construction section (model element) → Allow adjustment of rebar diameter (operation permission);

[0207] Define the trigger conditions for the association rule to take effect, for example:

[0208] Phase change trigger: When the project progress reaches 50%, modification permissions for the "secondary structure" level are automatically granted;

[0209] Role addition trigger: When a new construction team enters the site, the permission template for its corresponding construction section is automatically loaded;

[0210] Model update trigger: After the designer submits a model change, the construction party's right to modify the relevant components is automatically frozen, and the right to be unfrozen is required to be approved by the supervisor.

[0211] In one embodiment, the permission management smart contract includes the following:

[0212] Embed a set of conditional action rules for permission changes in the contract, for example:

[0213] Example rule 1: When the project phase changes from "design phase" to "construction phase", the designer's right to modify the components of the construction phase is automatically revoked;

[0214] Example Rule 2: When the construction party completes the concrete pouring of a certain floor (triggered by the PM system), grant them the right to adjust the electromechanical installation of the next floor.

[0215] Before the contract is deployed, it must be jointly signed by the construction unit, the construction contractor, and the regulatory agency to ensure that the rules meet the actual needs of the project and that there is no possibility of unilateral alteration.

[0216] Event-triggered execution:

[0217] The smart contract continuously listens for events pushed by the project management module, such as stage change events (e.g., "construction progress reaches 30%)", role addition / exit events (e.g., a new construction party enters the site), and model update events (e.g., the designer submits a new version of the BIM model).

[0218] When an event is triggered, the contract automatically matches the corresponding conditions in the rule base. For example, the event is: Construction progress reaches 50% → matching rule: "When the construction phase reaches 50%, grant permission to modify secondary structures". The action is to calculate the role (such as the construction party) and model unit (such as the secondary structure wall) whose permissions need to be adjusted. Before executing the permission change, the contract requires the operator to verify their identity through zero-knowledge proof. For example, the construction party needs to prove that it belongs to the project's authorized construction team, but does not need to disclose specific personnel information; the supervisor needs to prove that it has the qualifications for compliance review, but does not need to disclose personal privacy data.

[0219] Permission changes are executed and logs are generated:

[0220] Based on the rule matching results, the contract dynamically generates a new set of permissions. For example, it may revoke the designer's "modify" permission for components in the construction section, but retain the "view" permission; and grant the contractor "adjust" permission for the electromechanical equipment in the current construction section, limiting the scope of adjustment, such as allowing only ±5% modification of the pipe diameter.

[0221] The encrypted new permission set is broadcast to relevant nodes on the client side, such as the design and construction parties, via the blockchain and synchronized to the BIM model metadata. The "model-permission" binding is performed through ABE encryption in step one.

[0222] The contract automatically generates log entries containing timestamps, operation types, model versions, and the operator's digital certificate, such as "2025-07-25 14:30, the construction party (digital certificate ID: SP-001) triggered a 50% permission adjustment during the construction phase, and the new permission set has been distributed."

[0223] Linking with other steps:

[0224] When the contract is executed, the permission matrix generated in step one is invoked to ensure that permission changes comply with the dynamic association rules of model-role-stage, such as not exceeding spatial attribute restrictions; the operation log is synchronized to the third-party consortium blockchain audit module in real time (step three) to provide raw data for subsequent audits (such as the supervisor can trace whether permission changes are compliant through the logs).

[0225] In one embodiment, recalculating the permission matrix according to rules and verifying the operator's identity using zero-knowledge proof includes the following steps:

[0226] Event triggered:

[0227] When the project management module detects a phase change, such as the construction progress reaching 50%, it pushes an event notification to the smart contract, stating that "the construction phase has entered the second phase of the project." The smart contract matches the corresponding conditions in the preset rule base according to the event type (phase change), for example: "When the construction phase reaches 50%, grant the construction party the right to adjust the components of the second phase of the project, and at the same time revoke the design party's right to modify the area."

[0228] Dynamically recalculate the permission matrix:

[0229] The smart contract obtains the currently effective three-dimensional permission matrix (role-time sequence-spatial attribute) from step one. For example, the designer has the right to modify the "main structure" level in the early stage of construction.

[0230] Based on the event trigger condition (50% construction progress), the permission matrix is ​​dynamically adjusted:

[0231] Access granted: The construction party obtains the right to adjust the "Phase II Project Components" (spatial attribute binding);

[0232] Restricted access: The designer's right to modify "Phase II project components" is frozen (time-sequence attribute binding).

[0233] The adjusted permission matrix is ​​converted into a new permission set in encrypted format. For example, the construction party (role) has "adjustment" permission for the second-phase components (space) for 50% (time sequence) of the construction phase; the design party (role) has "no" permission for the second-phase components (space) for 50% (time sequence) of the construction phase.

[0234] Zero-knowledge proof authentication:

[0235] When the construction party needs to perform an adjustment operation, its client sends a request to the smart contract, along with a digital certificate, such as "Construction Party-SP-001". The smart contract generates a random challenge value ("random number-123"), requiring the operator to prove its identity legitimacy through zero-knowledge proof, for example: proof objective: "I am an authorized construction party for the project, and my digital certificate has not been revoked". The construction party's client generates a ZKP proof based on the challenge value and its private key, and submits it to the smart contract, for example, proof content: "I possess a private key that matches digital certificate SP-001, and the certificate status is valid". The smart contract checks the validity of the proof through the ZKP verification algorithm to ensure that the operator does indeed possess the private key of the corresponding digital certificate, and that the certificate has not been revoked or expired, and queries the certificate status through the blockchain.

[0236] Permission change:

[0237] If ZKP verification is successful, the smart contract will distribute the encrypted new permission set to the relevant nodes (such as the construction party's client) and synchronize it to the BIM model metadata (the "model-permission" binding is achieved through ABE encryption in step one). If verification fails, such as when the operator cannot provide valid proof, the contract will reject the permission change request and record the abnormal event (such as "Construction party-SP-002 attempted to illegally obtain the right to adjust the second phase components"). Regardless of whether the verification is successful or not, the contract will generate a log entry containing a timestamp, operation type, model version, and operator's digital certificate, and push it to the audit module in step three.

[0238] Dynamic association:

[0239] Permission adjustments rely on identity verification. The generation of new permission sets (such as granting construction parties the right to adjust permissions) requires the operator to be legitimate to avoid unauthorized operations. Identity verification ensures permission security, and zero-knowledge proofs ensure that only authorized roles can trigger permission changes, thus solving the subjective vulnerabilities of traditional manual review. A closed-loop linkage forms a security barrier: stage change → permission recalculation → identity verification → permission execution → log auditing, forming a complete chain of "event-driven - permission adjustment - security verification - result traceability".

[0240] In one embodiment, the construction of a three-party consortium blockchain audit module comprising the construction unit, the contractor, and the regulatory agency includes the following steps:

[0241] Initialize the consortium blockchain:

[0242] A consortium blockchain is jointly established by the construction company, the contractor, and the regulatory agency, with node permissions set:

[0243] Construction unit node: Has final approval authority and can query all audit logs;

[0244] Construction unit node: can only query logs related to its own operations (such as construction section component adjustment records);

[0245] Regulatory agency nodes: have full log query rights and can initiate compliance reviews;

[0246] The three parties complete node registration through digital certificates (such as “Construction-001” issued by the construction unit and “Construction-002” issued by the construction company), making their identities traceable.

[0247] Generate storage audit logs:

[0248] Each BIM operation generates a structured log entry:

[0249] Timestamp: The time when the operation occurred (accurate to the second);

[0250] Operation type: such as "Model Open", "Parameter Modification", "Permission Change";

[0251] Model version: The version number of the BIM model involved in the operation;

[0252] Operator identification: Digital certificate ID (e.g., “Design-001”, “Construction-002”);

[0253] Operation Summary: Briefly describe the operation object (e.g., "modify the diameter of the reinforcing bars in the beams and columns of the 5th floor").

[0254] Perform hash calculations on log entries to generate unique hash values, and store the hash values ​​on the blockchain to make the logs immutable;

[0255] Verification by multiple parties' consensus:

[0256] By employing an optimized PBFT (Practical Byzantine Fault Tolerance) algorithm, the consensus time is reduced to within 5 seconds:

[0257] Master node election: The master node is selected according to the rotation rules (such as the order of construction unit → construction unit → regulatory agency);

[0258] Log broadcasting: The master node broadcasts the newly generated log hash value to other nodes;

[0259] Voting verification: Each node verifies the hash value (e.g., checks whether the timestamp is valid and whether the operation type complies with permissions) and returns an "agree" or "reject" vote;

[0260] Consensus reached: When at least 2 / 3 of the nodes agree, the hash value is officially written into the blockchain, and audit confirmation is completed;

[0261] If a node has a dispute over the log content (such as a regulatory agency questioning the compliance of an operation), it can initiate a "dispute audit" process: lock the disputed log and suspend subsequent operations; the three parties review the original operation record through an offline meeting or encrypted channel; and update the log status (such as marking it as "compliant" or "non-compliant") after reaching an agreement.

[0262] Develop a visual audit interface:

[0263] Develop web or mobile interfaces that support querying logs by the following dimensions:

[0264] Role-based: Filter operation records for specific roles (such as construction parties);

[0265] Time dimension: Define a time range, such as "July 2025";

[0266] Operation type dimension: Focus on specific operations, such as "permission change";

[0267] Provides an operation sequence visualization function to display all the operations of a certain role within a specific time period, such as "Construction Party - SP-001 modified the diameter of the steel bars in the beam and column components on the 5th floor on July 20th";

[0268] De-identified data processing:

[0269] Extract the features needed for AI training from the audit logs, while removing sensitive information:

[0270] Retained features: operation time interval, operation type sequence, model version change frequency;

[0271] Removed features: operator's digital certificate ID, specific parameter value (specific value of rebar diameter);

[0272] Set a daily scheduled task at midnight to package the anonymized audit data (CSV format) and push it to the AI ​​training module in step four through a secure channel;

[0273] In one embodiment, the anomaly detection module for constructing the LSTM-CNN hybrid model includes the following steps:

[0274] Data preprocessing:

[0275] The de-identified BIM event logs are received from the audit module in step three, including operation timestamps, operation type sequences (e.g., "model open - parameter modification - save"), and model version change records. Key features are retained: operation time intervals (e.g., whether the interval between two modification operations is abnormal); operation type sequences (e.g., "modifying core parameters outside of working hours"); and model version jumps (e.g., jumping directly from V1.0 to V3.0, skipping V2.0). Sensitive information such as the operator's digital certificate ID and specific parameter values ​​(e.g., the specific value of the rebar diameter) are removed. Normal operations are marked as "0", and abnormal operations (e.g., unauthorized modifications, operations outside of working hours) are marked as "1", forming a labeled training dataset.

[0276] Designing an LSTM-CNN hybrid model architecture:

[0277] The input layer receives preprocessed operation sequence data (shape: [time step, number of features]); the LSTM layer captures the temporal dependencies in the operation sequence, such as "save immediately after modifying parameters" is a normal mode, while "save the next day after modification" may be abnormal, processes time series features, and outputs the hidden state; the CNN layer extracts local combination features of operation types, such as "model open + parameter modification" is a normal combination, while "model open + permission change" may be abnormal, performs convolution operations on the hidden state output by the LSTM, and extracts local patterns; the merging layer concatenates the outputs of the LSTM and CNN, and inputs them into the fully connected layer for classification (normal / abnormal).

[0278] Training and optimizing the model:

[0279] Load the parameters of the LSTM-CNN model pre-trained in a similar engineering scenario (such as a subway construction project) to accelerate local training and improve initial accuracy; fine-tune the model using anonymized project data to optimize parameters to adapt to the current project's operational mode (e.g., adjust the number of hidden units in the LSTM and the kernel size of the CNN); divide the dataset into a training set (70%), a validation set (20%), and a test set (10%); adjust hyperparameters such as the learning rate and batch size using the validation set, and employ an early stopping mechanism to prevent overfitting (e.g., stop training if the loss does not decrease after 5 consecutive validation rounds).

[0280] Anomaly Detection and Response:

[0281] After a new operation log is generated, it is immediately input into the trained model, which outputs anomaly probability values. When the probability value exceeds a preset threshold and anomalies are detected three times consecutively, a three-level response mechanism is triggered:

[0282] Level 1 Response (Model Version Rollback):

[0283] Automatically roll back the BIM model to the previous normal version (e.g., roll back from V3.0 to V2.0) to ensure that construction continues to use the trusted model; link the smart contract in step two to freeze the permissions of the current operator (e.g., the adjustment right of the construction party-SP-001 is temporarily revoked).

[0284] Level II Response (Early Warning Notification):

[0285] Send an alert notification to the supervisor containing operation video clips, timestamps, and operation type (e.g., "2025-07-25 23:15, Construction Party - SP-001 attempted to modify core parameters"); the alert notification is sent through an encrypted channel, making the information visible only to the supervisor.

[0286] Level 3 Response (Secondary Authentication):

[0287] Initiate facial recognition or fingerprint recognition to require the operator to perform secondary authentication; if authentication fails, permanently freeze their permissions and mark them as a "high-risk operator";

[0288] Closed-loop optimization:

[0289] Detected abnormal events (such as "parameter modification outside of working hours") are fed back to Step 1. The permission matrix parameters are dynamically adjusted to add spatiotemporal constraints (such as "modification of core parameters is prohibited during the construction phase from 22:00 to 6:00"), and the role permission template is modified (such as restricting the adjustment range of specific components by the construction party). The model is incrementally trained monthly using the latest de-identified data to maintain the ability to identify emerging abnormal patterns (such as new unauthorized operation methods). The updated model must be deployed after consensus confirmation by the three-party consortium blockchain (Step 3) to ensure the credibility of the detection logic.

[0290] In one embodiment, the abnormal event is fed back to step one to dynamically adjust the permission matrix parameters, including the following steps:

[0291] Feedback on abnormal events:

[0292] When the LSTM-CNN model in step four detects three consecutive deviations from the baseline, it is automatically marked as an "abnormal event requiring optimization"; a feedback packet containing details of the abnormal event is generated, including:

[0293] Exception types: such as "operation outside of working hours" and "unauthorized access";

[0294] Operator identification: Digital certificate ID (e.g., "Construction Party-SP-001");

[0295] Operation content: The specific components, parameters, or permissions to be modified, such as "modify the diameter of the steel bars in the beams and columns on the 5th floor";

[0296] Time of occurrence: A timestamp accurate to the second (e.g., "2025-07-25 23:15");

[0297] Analysis of the cause of the anomaly:

[0298] By combining the audit logs (Step 3) and the permission matrix (Step 1), analyze the cause of the anomaly:

[0299] Insufficient spatiotemporal constraints: The permission matrix does not restrict modifications to core parameters during non-working hours;

[0300] Excessive role permissions: The construction party was granted the right to adjust components beyond its construction section;

[0301] Phase mismatch error: The model version is out of sync with the project phase, causing errors in permission calculations;

[0302] Based on the root cause analysis results, the directions for optimizing the permission matrix are determined as follows:

[0303] Add spatiotemporal constraints: Bind a rule to the permission matrix that "modification of core parameters is prohibited outside of working hours";

[0304] Reduce role permissions: restrict the construction party's adjustment permissions to components of "current construction section + adjacent 1 floor";

[0305] Correct phase mapping: Ensure that the model version strictly corresponds to the project phase, such as the V2.0 model only taking effect when the construction phase is 50% complete;

[0306] Dynamically adjust permission matrix parameters:

[0307] Based on the adjustment objectives, modify the three-dimensional attribute binding rules of the permission matrix, for example:

[0308] Time attribute refinement: The "construction phase" is divided into "daytime (6:00-22:00)" and "nighttime (22:00-6:00)". Core parameters cannot be modified during the nighttime period;

[0309] Spatial attributes are tightened: the spatial permissions of the construction party are tightened from the "single building" level to the "floor + construction section" level (e.g., only the "1# office building - 5th floor - east section" component can be adjusted);

[0310] Role permission template optimization: Added "Parameter Review" permission for designers (can only view the construction party's modification records, cannot directly modify them);

[0311] After the adjustment, the system automatically checks the compatibility of the new rules with existing rules, for example:

[0312] Conflict detection: Ensure that the rule "prohibit modification of core parameters at night" does not conflict with the rule "modification is allowed during emergency repair periods";

[0313] Coverage verification: Confirm that the new rules cover all similar abnormal scenarios (such as modifying device parameters outside of working hours, or adjusting unauthorized components without authorization).

[0314] Verify the adjustment effect:

[0315] Simulate the adjusted permission matrix in a test environment to verify its control effect on typical scenarios, such as:

[0316] Scenario 1: The construction team attempts to modify core parameters at night → triggers an insufficient permissions warning;

[0317] Scenario 2: The designer attempts to modify components in an unauthorized construction section → triggering an unauthorized access warning;

[0318] After verification, the adjusted permission matrix will be synchronized to the dynamic permission modeling module in step one, and the encryption policy file will be regenerated (embedded with BIM model metadata through the ABE algorithm).

[0319] Continuous optimization:

[0320] Step 2 (Smart Contract): Receive the new permission matrix and update the condition-action rules in the rule base (e.g., "Construction parties are prohibited from modifying core parameters during nighttime"). Step 3 (Audit Module): Record permission matrix adjustment events and generate a comparison log containing before and after the adjustment (e.g., "2025-07-26 10:00, nighttime operation restrictions added to the permission matrix"). Step 4 (AI Model): Re-input the adjusted normal operation mode into the LSTM-CNN model and update the behavior baseline (e.g., "No core parameter modification at night" becomes the new baseline). Continuously monitor the effect of the adjusted permission matrix. If a similar anomaly is detected again (e.g., the construction party modifies parameters through other paths at night), a new round of feedback-adjustment loop is triggered, forming a continuous optimization mechanism of "detection-analysis-adjustment-verification".

[0321] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for secure management of BIM data in engineering construction, characterized in that, include: Step 1: Construct a three-dimensional permission matrix to quantitatively bind role attributes, temporal attributes, and spatial attributes; By using an attribute-based encryption algorithm, permission parameters are embedded into BIM model metadata to construct a dynamic association between model, role, and stage. The matrix serves as input to drive the execution of the smart contract in step two. Step 2: Deploy a permission management smart contract on the consortium blockchain and preset a permission change rule base; When a phase change event is triggered by project management, the smart contract automatically calls the permission matrix generated in step one and performs the following operations: calls the BIMBase platform API to obtain the latest model version, recalculates the permission matrix according to the rules, verifies the identity of the operator through zero-knowledge proof, and finally distributes the encrypted new permission set to the relevant nodes. The operation log is synchronized to the audit module in step three in real time. Step 3: Construct a three-party consortium blockchain audit module that includes the construction unit, the contractor, and the regulatory agency. The module generates a hash value containing timestamp, operation type, and model version for each BIM operation, and uses an improved PBFT consensus algorithm to confirm the audit within 5 seconds; develop a BIM event log visualization interface that supports multi-dimensional retrieval by role, time, and operation type, and periodically input the de-identified audit data into the AI ​​training module in Step 4. Step 4: Construct an anomaly detection module for the LSTM-CNN hybrid model; First, extract operation sequence features from the BIM event log, and construct a normal behavior baseline model through transfer learning; When three consecutive operations deviating from the baseline are detected, the module automatically triggers a three-level response mechanism: model version rollback, sending an early warning notification containing operation video to the supervisor, and initiating secondary facial recognition authentication; Abnormal events are fed back to Step 1, and the permission matrix parameters are dynamically adjusted.

2. The method for secure management of BIM data in engineering construction according to claim 1, characterized in that, The construction of the three-dimensional permission matrix, which quantifies and binds role attributes, temporal attributes, and spatial attributes, includes the following steps: Define category attributes: The role attributes clearly define the role types of those participating in collaborative work, including designers, construction companies, supervisors, and owners, and define basic permission levels for each role; assign unique identifiers to roles and associate them with permission tags; Time sequence attribute: Divide the project into stages including design, construction and operation and maintenance according to the entire project life cycle, define the permission opening rules for each stage, map the project progress percentage to time sequence label, and dynamically adjust the permission scope; Spatial attributes: The BIM model is divided into hierarchical spatial units, and operation permissions are defined for each unit. A unique ID is assigned to each spatial unit, and operation restrictions are associated with it. Quantization binding of three-dimensional properties: Create a 3D table where rows represent role attributes, columns represent temporal attributes, and depth represents spatial attributes, forming a three-dimensional permission model of role × temporal × spatial. The designer has full modification rights to the main structure during the design phase, but retains only the right to view parameters during the construction phase. Define the linkage logic between attributes, convert the quantified permission matrix into an encrypted policy file, and embed the policy into the BIM model metadata through the ABE algorithm. This enables the model file to carry dynamic permission information and perform real-time binding between the model, role, and phase. Validation optimization: Select typical collaborative work scenarios to verify whether the permission matrix restricts operations as expected, check whether there are logical contradictions in attribute binding, and resolve conflicts by adjusting quantification parameters; set the update trigger conditions for the permission matrix so that the matrix can adapt to the progress of the project.

3. The method for secure management of BIM data in engineering construction according to claim 1, characterized in that, The construction of the dynamic association between the model, roles, and stages includes the following steps: Model structured decomposition: The BIM model is divided into hierarchical units according to physical structure or functional modules: Level 1 unit, the entire project; Level 2 unit, individual building; Level 3 unit, floor or functional area; Level 4 unit, specific components and parameters; each model unit is assigned a unique identifier so that the model structure can be accurately located and access controlled. Define role permissions: List all roles involved in the collaborative work, including the designer, construction contractor, supervisor, and owner, and define their core responsibilities: the designer is responsible for model creation and modification, the construction contractor is responsible for parameter adjustment and verification during the construction phase, the supervisor is responsible for operational compliance review, and the owner is responsible for final approval and adjustments during the operation and maintenance phase; set basic permission scopes for each role, with the designer having modification permissions by default, limited to the design phase; the construction contractor having view permissions by default, which can be upgraded to adjustment during the construction phase; Project phases: Divide the project into phases based on its entire lifecycle and set milestone events for phase transitions; define the permission granting logic for each phase: Design phase: The design team has the right to modify all components of the model, while other roles are only allowed to view them; Construction phase: The construction party gains the right to adjust the components of the current construction section, while the design party's authority is reduced to parameter review; During the operation and maintenance phase: the owner gains the right to modify equipment parameters, while the permissions of other roles are frozen; Dynamic correlation of three elements: Establish a 3D mapping table of model unit-role-stage to clarify the operation permissions of different roles on different units of the model at different stages; define the triggering conditions for the association rules to take effect. Phase change trigger: When the project progress reaches 50%, the permission to modify the secondary structure hierarchy is automatically granted; Role addition trigger: When a new construction team enters the site, the permission template for its corresponding construction section is automatically loaded; Model update trigger: After the designer submits a model change, the construction party's right to modify the relevant components is automatically frozen, and the right to be unfrozen is required to be approved by the supervisor.

4. The method for secure management of BIM data in engineering construction according to claim 1, characterized in that, The permission management smart contract includes the following: The contract embeds a set of action rules for permission changes. Before deployment, the contract must be jointly signed by the construction unit, the construction company, and the regulatory agency to ensure that the rules meet the actual needs of the project and that there is no possibility of unilateral tampering. The smart contract continuously listens for events pushed by the project management module. When an event is triggered, the contract automatically matches the corresponding conditions in the rule base. Before executing permission changes, the contract requires the operator to verify their identity through zero-knowledge proof. Based on the rule matching results, the contract dynamically generates a new permission set, granting the construction party the right to adjust the electromechanical equipment in the current construction section, while limiting the scope of adjustment. The encrypted new permission set is broadcast via the blockchain to relevant nodes on the client side, such as the design party and the construction party, and synchronized to the BIM model metadata. Model-permission binding is performed through ABE encryption in step one. The contract automatically generates log entries containing timestamps, operation types, model versions, and the operator's digital certificate. When the contract is executed, the permission matrix generated in step one is called to ensure that permission changes conform to the dynamic association rules of model-role-stage. The operation log is synchronized to the third-party consortium blockchain audit module in real time, providing raw data for subsequent audits.

5. The method for secure management of BIM data in engineering construction according to claim 1, characterized in that, The process of recalculating the permission matrix according to the rules and verifying the identity of the operator using zero-knowledge proof includes the following steps: When the project management module detects a phase change, the smart contract matches the corresponding conditions in the preset rule base according to the event type; the smart contract obtains the currently effective three-dimensional permission matrix from step one, and dynamically adjusts the permission matrix in conjunction with the event trigger bar: Granted permissions: The construction company obtains the right to adjust the components of the second phase of the project; Restricted access: The designer's right to modify components of the second phase of the project has been frozen; The adjusted permission matrix is ​​converted into a new permission set in encrypted format. During the construction phase, the construction party has 50% of the adjustment permissions for the second-phase components; the design party has no permissions for the second-phase components during the construction phase. When the construction party needs to perform an adjustment operation, its client sends a request to the smart contract, along with a digital certificate. The smart contract generates a random challenge value, requiring the operator to prove its identity legitimacy through zero-knowledge proof. The construction party's client generates a ZKP proof based on the challenge value and its private key, and submits it to the smart contract. The smart contract checks the validity of the proof through the ZKP verification algorithm to ensure that the operator does indeed possess the private key of the corresponding digital certificate, and that the certificate has not been revoked or expired. The certificate status is queried through the blockchain. If ZKP verification is successful, the smart contract distributes the encrypted new permission set to the relevant nodes and synchronizes it to the BIM model metadata; if verification fails, the contract rejects the permission change request and records the abnormal event; regardless of whether the verification is successful or not, the contract generates a log entry containing a timestamp, operation type, model version, and operator's digital certificate, and pushes it to the audit module in step three; permission adjustment depends on identity verification, and the generation of the new permission set must be based on the operator's legitimate identity to avoid unauthorized operations; identity verification ensures permission security, and zero-knowledge proofs enable only authorized roles to trigger permission changes.

6. The method for secure management of BIM data in engineering construction according to claim 1, characterized in that, The construction of the three-party consortium blockchain audit module, which includes the construction unit, the contractor, and the regulatory agency, includes the following steps: A consortium blockchain is jointly established by the construction company, the contractor, and the regulatory agency, with node permissions set: Construction unit node: Has final approval authority and can query all audit logs; Construction unit node: can only query logs related to its own operations; Regulatory agency nodes: have full log query rights and can initiate compliance reviews; The three parties register nodes using digital certificates, making their identities traceable. Each BIM operation generates a structured log entry: timestamp, operation type, model version, operator identifier, and operation content summary. The log entry is hashed to generate a unique hash value, which is then stored on the blockchain to ensure the log is immutable. An optimized PBFT algorithm is used to compress the consensus time to within 5 seconds: the master node is selected according to the rotation rule. Log broadcasting: The master node broadcasts the newly generated log hash value to other nodes; Voting verification: Each node verifies the hash value and returns either "agree" or "reject" the vote; Consensus reached: When at least 2 / 3 of the nodes agree, the hash value is officially written into the blockchain for audit confirmation; If a node has a dispute over the log content, it can initiate a dispute audit process: lock the disputed log and suspend subsequent operations; the three parties review the original operation record through an offline meeting or encrypted channel; and update the log status after reaching an agreement. Develop a web or mobile interface that supports querying logs by the following dimensions: role, time, and operation type. Provide an operation sequence visualization function to display all operations performed by a role within a specific time period. Extract the features needed for AI training from the audit logs, while removing sensitive information: Retained features: operation time interval, operation type sequence, model version change frequency; Removed features: operator's digital certificate ID, specific parameter values; Set a daily scheduled task at midnight to package the anonymized audit data and push it to the AI ​​training module in step four through a secure channel.

7. The method for secure management of BIM data in engineering construction according to claim 1, characterized in that, The anomaly detection module for constructing the LSTM-CNN hybrid model includes the following steps: Data preprocessing: The de-identified BIM event logs are received from the audit module in step three, including operation timestamps, operation type sequences, and model version change records. Key features are retained: operation time intervals; operation type sequences; model version jumps. Sensitive information such as the operator's digital certificate ID and specific parameter values ​​are removed. Normal operations are marked as 0, and abnormal operations are marked as 1, forming a labeled training dataset. Designing an LSTM-CNN hybrid model architecture: The input layer receives the preprocessed operation sequence data; the LSTM layer captures the temporal dependencies in the operation sequence, processes the time series features, and outputs the hidden state; the CNN layer extracts the local combined features of the operation type, performs convolution operations on the hidden state output by the LSTM, and extracts the local pattern; the merging layer concatenates the outputs of the LSTM and CNN, and inputs them into the fully connected layer for classification. Training and optimizing the model: Load the parameters of the LSTM-CNN model pre-trained in a similar engineering scenario to accelerate local training and improve initial accuracy; fine-tune the model using anonymized project data to optimize parameters to adapt to the current project's operational mode; divide the dataset into training, validation, and test sets; adjust the learning rate and batch size hyperparameters using the validation set, and employ an early stopping mechanism to prevent overfitting; Anomaly Detection and Response: After a new operation log is generated, it is immediately input into the trained model, which outputs anomaly probability values. When the probability value exceeds a preset threshold and anomalies are detected three times consecutively, a three-level response mechanism is triggered: Level 1 Response: Automatically roll back the BIM model to the previous normal version, allowing construction to continue using the trusted model; link the smart contract in step two to freeze the permissions of the current operator. Level 2 Response: The system sends an early warning notification to the supervisor, which includes video clips of the operation, timestamps, and operation type. The notification is sent through an encrypted channel, ensuring that the information is only visible to the supervisor. Level 3 Response: Initiate facial or fingerprint recognition and require the operator to perform secondary authentication; if authentication fails, permanently freeze their permissions and mark them as a high-risk operator. Closed-loop optimization: The detected abnormal events are fed back to step one, and the parameters of the permission matrix are dynamically adjusted to add spatiotemporal constraints and modify the role permission template. The model is incrementally trained monthly using the latest de-identified data to maintain the ability to identify emerging abnormal patterns. The updated model must be deployed after being confirmed by the consensus of the three-party consortium blockchain to improve the credibility of the detection logic.

8. The method for secure management of BIM data in engineering construction according to claim 1, characterized in that, The abnormal event is reported back to step one, dynamically adjusting the permission matrix parameters, including the following steps: Feedback on abnormal events: When the LSTM-CNN model in step four detects three consecutive operations that deviate from the baseline, it is automatically marked as an anomalous event that needs optimization; a feedback package containing details of the anomalous event is generated, including the anomaly type, operator identifier, operation content, and occurrence time; Analysis of the cause of the anomaly: By combining audit logs and permission matrix, analyze the cause of the anomaly: Insufficient spatiotemporal constraints: The permission matrix does not restrict modifications to core parameters during non-working hours; Excessive role permissions: The construction party was granted the right to adjust components beyond its construction section; Phase mismatch error: The model version is out of sync with the project phase, causing errors in permission calculations; Based on the root cause analysis results, the directions for optimizing the permission matrix are determined as follows: Add spatiotemporal constraints: Bind rules to the permission matrix to prohibit modification of core parameters during non-working hours; Reduce role permissions: Restrict the construction party's adjustment permissions to the current construction section plus components on the adjacent floor; Correcting the phase mapping: ensuring that the model version strictly corresponds to the project phase; Dynamically adjust permission matrix parameters: Based on the adjustment objectives, modify the three-dimensional attribute binding rules of the permission matrix: Time attribute refinement: The construction phase is divided into daytime and nighttime, and core parameters cannot be modified during nighttime. Spatial attribute tightening: The spatial permissions of the construction party are tightened from the single building level to the floor + construction section level; Role permission template optimization: Add parameter review permission for designers; After the adjustment, the system will automatically check the compatibility between the new rules and existing rules: Conflict detection: Ensures that the rule prohibiting modification of core parameters at night does not conflict with the rule allowing modification during emergency repair periods; Coverage verification: Confirm that the new rule covers all similar abnormal scenarios; Verify the adjustment effect: The adjusted permission matrix is ​​simulated in the test environment to verify its control effect on typical scenarios. After the verification is successful, the adjusted permission matrix is ​​synchronized to the dynamic permission modeling module in step one, and the encryption policy file is regenerated. Continuous optimization: Step 2 receives the new permission matrix and updates the condition-action rules in the rule base; Step 3 records the permission matrix adjustment event and generates a comparison log containing the before and after adjustment; Step 4 re-inputs the adjusted normal operation mode into the LSTM-CNN model and updates the behavior baseline; continuously monitors the effect of the adjusted permission matrix, and if a similar anomaly is detected again, a new round of feedback-adjustment loop is triggered, forming a continuous optimization mechanism of detection-analysis-adjustment-verification.

Images