A double-layer foamed ceramic wallboard advanced hole reservation BIM collaborative design method

Abstract

The application relates to the technical field of building information modeling and discloses a double-layer foamed ceramic wallboard advanced hole reservation BIM collaborative design method, which comprises the following steps: after receiving a design operation, a preprocessing transaction is generated; localized real-time verification is performed based on internal constraint rules of components to provide instant feedback; after verification, it is determined whether distributed negotiation needs to be started based on external influence rules; if so, potential influence notifications are broadcast to affected participants, and negotiation responses including approval, rejection or approval with conditions are collected; and the responses are comprehensively judged based on preset adjudication rules to determine the final disposal result of the preprocessing transaction. Through the pre-verification and negotiation mechanism, the traditional post-conflict resolution is moved forward, the strong consistency of model data and the traceability of design decisions in a multi-user environment are ensured, and the efficiency and quality of collaborative design are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of building information modeling technology, specifically to a BIM collaborative design method for pre-reserved holes in double-layer foamed ceramic wall panels. Background Technology

[0002] With the continuous improvement of informatization and industrialization in the construction industry, BIM technology has become a core tool for modern building design, construction, and operation and maintenance. In the design process of large and complex projects, multi-disciplinary and multi-team collaboration is often involved. Designers from different disciplines may modify the same component or propose changes to related components in their respective BIM models. Taking the reservation of openings in building structures as an example, structural engineers need to ensure that the load-bearing capacity of the component is not affected, while mechanical and electrical engineers need to reserve installation space for pipes and equipment on the same component. Such cross-design and modification are common aspects of project collaboration.

[0003] However, existing BIM collaborative design tools generally have limitations in handling such multidisciplinary collaborative design conflicts. Traditional methods often rely on centralized model management servers or manual coordination, leading to delayed discovery and inefficient resolution of design conflicts. When designers from multiple disciplines concurrently modify the same or related components, existing systems typically struggle to provide timely warnings or effectively prevent potential conflicts in the early stages of design. Design conflicts are often discovered only during model merging, clash detection, or later design review stages, at which point resolving them requires significant time and resources for rework and communication. This delayed conflict discovery and resolution mechanism not only increases the overall design cycle and cost of the project but may also introduce new errors due to untimely or misunderstandings in information transmission, severely impacting design quality and collaborative efficiency. Furthermore, for design operations such as reserved openings that directly affect the integrity and functionality of components, ensuring compliance with the constraints of the components themselves and the requirements of relevant disciplines while maintaining design freedom is a prominent challenge currently facing BIM collaborative design. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a BIM collaborative design method for pre-reserving holes in double-layer foamed ceramic wall panels. This method solves the problems of delayed conflict detection and low efficiency in existing BIM collaborative design technologies. This leads to design rework when multiple disciplines are designing concurrently, especially when pre-reserving holes in key components such as double-layer foamed ceramic wall panels, thereby increasing project costs and extending the design cycle.

[0005] To achieve the above objectives, the present invention provides a BIM collaborative design method for pre-reserved holes in double-layer foamed ceramic wall panels, comprising the following steps:

[0006] S1. Upon receiving a hole reservation design operation for a source-constrained digital component asset, generate a preprocessed transaction containing the proposed geometry.

[0007] S2. Based on the internal constraint rules of the source-constrained digital component assets, perform localized real-time verification on the preprocessed transaction;

[0008] S3. After the localized real-time verification is passed, based on the external influence rules of the source-constrained digital component assets, determine whether the preprocessing transaction needs to initiate distributed negotiation.

[0009] S4. If distributed negotiation needs to be initiated, generate and broadcast a potential impact notification to the distributed design agent of the target constrained digital component asset, and collect the negotiation responses returned by each of the distributed design agents.

[0010] S5. Based on the collected negotiation responses, execute a final ruling to determine the outcome of the pre-processed transaction;

[0011] S6. If the final decision is to approve, then a final transaction is constructed and appended to the distributed transaction logs of each participant in the network through a consistency appending protocol.

[0012] S7. Each participating party updates its local model data in principle based on the final transaction committed in its distributed transaction log.

[0013] Preferably, the step of performing localized real-time verification includes:

[0014] Execute the internal constraint function, the return value of which is the logical AND of the calculation results of all individual internal constraint rule functions in the set of internal constraint rules of the source constrained digital component asset.

[0015] Preferably, the step of determining whether the preprocessing transaction needs to initiate distributed negotiation includes:

[0016] Iteratively evaluate each external impact rule in the set of external impact rules for the source-constrained digital component assets; determine that distributed negotiation needs to be initiated if and only if the triggering condition of at least one of the external impact rules is met.

[0017] Preferably, the potential impact notification is a structured data object that includes: a transaction identifier associated with the preprocessing transaction, an impact type, and a data payload containing the proposed geometry.

[0018] Preferably, the negotiation response is a structured data object that includes a response status; the value of the response status is selected from: approval, rejection, or conditional approval.

[0019] Preferably, the step of collecting negotiation responses further includes a timeout handling mechanism:

[0020] After broadcasting the potential impact notification, a timeout timer is started; if no negotiation response is received from the distributed design agent of a target constrained digital component asset within the preset timeout threshold, a negotiation response with a rejection status is generated for the target constrained digital component asset.

[0021] Preferably, the step of executing the final ruling follows the following hierarchical evaluation rules:

[0022] If the response status of any of the collected negotiation responses is rejection, then the processing result of the preprocessed transaction is disapproval.

[0023] If there is no negotiation response with a rejection status, but there is at least one negotiation response with a conditional approval status, then the outcome of the preprocessed transaction is pending modification.

[0024] If all collected negotiation responses are approved, then the processing result of the preprocessed transaction is approved.

[0025] Preferably, the step of constructing the final transaction includes:

[0026] The data from the preprocessed transaction is aggregated with the negotiation metadata field containing all collected negotiation responses to form the final transaction.

[0027] Preferably, the consistency appending protocol includes:

[0028] Proposal Phase: In this phase, the initiator broadcasts the final transaction.

[0029] Write-ahead phase: In this phase, the receiver verifies the final transaction and writes it to the local distributed transaction log in a pending-commit state;

[0030] Submission Execution Phase: In this phase, after the initiator collects confirmations from all recipients, it broadcasts a submission instruction, and all participants update the status of the final transaction to "submitted".

[0031] A BIM collaborative design system for pre-drilled holes in double-layer foamed ceramic wall panels includes:

[0032] The preprocessing transaction generation module is used to generate a preprocessing transaction containing the proposed geometry state after receiving the hole reservation design operation;

[0033] The localization verification module is used to perform localized real-time verification on the preprocessed transaction based on the internal constraint rules of the source-constrained digital component assets.

[0034] The negotiation initiation module is used to determine whether distributed negotiation needs to be initiated based on external impact rules after the localized real-time verification is passed, and to generate and broadcast potential impact notifications when necessary.

[0035] The adjudication and response management module is used to collect negotiation responses returned by other distributed design agent modules and execute the final adjudication based on preset rules;

[0036] The transaction consistency module is used to construct a final transaction when the decision result is approval, and to ensure that the final transaction is synchronously appended to the distributed transaction logs of each participant in the network through a consistency appending protocol.

[0037] The model synchronization module is used to update the local model data in principle based on the content of the distributed transaction log.

[0038] This invention provides a BIM collaborative design method for pre-drilling holes in double-layer foamed ceramic wall panels. It offers the following advantages:

[0039] 1. This invention significantly improves design efficiency and quality by introducing localized real-time verification and distributed negotiation mechanisms during the collaborative design process. After the user initiates a design operation, the system immediately verifies the internal constraints of the geometric changes reserved for holes. After passing the verification, it initiates distributed negotiation with other relevant parties based on external influence rules. This pre-intervention verification and negotiation mode replaces the inefficient process of discovering conflicts and making repeated modifications after the fact in traditional collaborative design. It avoids the spread of non-compliant or conflict-causing design schemes in the early stages, thereby greatly reducing the number of design iterations and rework costs.

[0040] 2. This invention achieves high consistency and traceability of BIM model data during collaborative design; by introducing a consistent append protocol for distributed transaction logs and an atomic update mechanism for client models, it ensures that all participants synchronously perceive and uniformly apply design changes such as hole reservations; finally, the negotiation metadata attached to the transaction records the responses and decision-making processes of all participants, so that each approved design change has complete negotiation proof. This not only ensures the global consistency of the design status, but also provides a clear audit path and accountability basis for design decisions.

[0041] 3. This invention transforms design specifications into intelligent executable code through C-EMCA-encapsulated internal constraint rules and external influence rules, and performs flexible assessments in the early stages of design. When potential conflicts arise, the system guides the participants to reach a consensus through a negotiation mechanism, rather than simply rejecting changes. This approach allows designers to explore and optimize within a legal and compliant framework while ensuring the overall technical requirements and specifications of the project, thereby enhancing the flexibility and innovation space of the design. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the system architecture of the present invention;

[0043] Figure 2 This is the overall flowchart of the collaborative design transaction processing of the present invention. Detailed Implementation

[0044] 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.

[0045] Example:

[0046] Please see the appendix Figure 2 This invention provides a BIM collaborative design method for pre-reserved holes in double-layer foamed ceramic wall panels, comprising the following steps:

[0047] S1. Construction and Environment Initialization of Constrained Digital Component Assets: Before the collaborative design begins, a constrained digital component asset module containing internal constraint rules and external influence rules is constructed, and the distributed collaborative environment of all participants is initialized, including a distributed design agent module and a transaction consistency module for maintaining data consistency.

[0048] S2. Real-time capture of design intent and generation of preprocessed transactions: When any user performs a design operation, its local distributed design agent module captures the operation intent in real time and encapsulates it into a temporary, unverified preprocessed transaction.

[0049] S3. Localized real-time verification based on component internal constraints: The distributed design agent module affected by the operation calls the internal constraint rules defined in the constrained digital component asset module of the target component to perform the first stage of localized verification of the preprocessed transaction.

[0050] S4. Constraint Propagation and Multi-Agent State Negotiation Based on External Influence Rules: If localization verification passes, the distributed design agent module evaluates whether the operation triggers an external influence rule. If triggered, it automatically broadcasts a potential impact notification to the distributed design agent modules corresponding to other affected components and initiates a multi-party state negotiation process.

[0051] S5. Aggregation of negotiation results, final decision and transaction confirmation: The distributed design agent module that initiates the transaction is responsible for collecting all negotiation responses and making a final decision on the pre-processed transaction according to the preset decision logic.

[0052] S6. Broadcasting and Distributed State Synchronization of Final Transactions: The preprocessed transactions that have passed final adjudication are constructed into final transactions and broadcast to all participants. The transaction consistency module of each participant records this transaction in the distributed transaction log and synchronously updates its local model.

[0053] S7. Each participant atomically updates its local model data based on the final transactions committed in its distributed transaction log.

[0054] The construction and environment initialization of constrained digital component assets provide the basic data objects and operating environment for subsequent real-time verification and collaborative negotiation.

[0055] Constrained digital component assets are a specific data structure used to replace or enhance traditional BIM components in a BIM environment. This data structure encapsulates the geometric representation of a component with computer-executable engineering constraints, transforming BIM components from static geometric objects into computational objects capable of self-state verification and external interaction.

[0056] Constrained digital component assets are defined at the data level as a collection of data comprising the following components: a geometric and physical model, a set of constraint rules, and current state data. The geometric and physical model includes information such as the component's three-dimensional geometry, material properties, and topological relationships; its construction method is well-known in the field and will not be elaborated upon here.

[0057] This step, specifically the method for constructing constrained digital component assets, may include the following sub-steps:

[0058] Define the data schema for the constraint rule set. This data schema defines the storage structure for two types of rules in a machine-readable format: internal constraint rules and external influence rules.

[0059] Implement internal constraint rules. Internal constraint rules are a set of logical functions used to determine the validity of a single design change imposed on a component itself. This set can specifically include:

[0060] The minimum boundary distance rule is used to calculate the minimum distance between the boundary of the proposed geometric change and the boundary of the component's own geometric model, and to determine whether the distance is greater than a preset threshold.

[0061] The multi-geometry spacing rule is used to calculate the minimum distance between two or more proposed geometric changes and determine whether this distance meets structural safety or construction process requirements. The judgment threshold of this rule can be a fixed value or a function dynamically calculated based on parameters such as the size and shape of the geometric change.

[0062] Size limit rules are used to determine whether the dimensions of a proposed geometric change exceed the maximum allowable value without requiring additional reinforcement.

[0063] Disable region rules, which are used to store one or more spatial coordinate regions defined within the component geometry model and determine whether proposed geometric changes spatially interfere with these regions.

[0064] Implement external influence rules. External influence rules define the conditional action logic for broadcasting a notification to other components in the system when a component's own state undergoes a specific change. Each external influence rule specifically includes:

[0065] The trigger condition is a logical expression that takes as input parameters a proposed geometric change. The rule is triggered when the expression evaluates to true. A trigger condition can be that the proposed hole size exceeds a threshold defined in the size constraint rule.

[0066] A broadcast action defines the operation the system must perform when a triggering condition is met. This action specifically specifies the type of potential impact notification to be generated and the category or instance identifier of one or more target components that need to receive the notification. For example, a broadcast action broadcasts a potential impact notification of structural weakening type to all beam components structurally adjacent to this wall panel.

[0067] The geometric and physical models are associated with constraint rule sets. By data binding specific instances of the geometric and physical models with configured constraint rule set instances, a complete constrained digital component asset is generated that can be used by the collaborative design system. When this asset is instantiated into the BIM model, it also includes current state data to record its dynamic changes, a list of existing holes and their attributes.

[0068] After the constrained digital component assets are constructed, the system needs to initialize the distributed collaborative environment. This initialization process provides the necessary runtime environment for subsequent collaborative design operations, ensuring that the design agents of all participants can communicate normally and maintain the synchronization starting point of data state.

[0069] The initialization process of a distributed collaborative environment may specifically include the following sub-steps:

[0070] Activate the distributed design agent and establish a session network. When a user launches the collaborative design client and selects to join a design project, the distributed design agent module bound to that user is instantiated and activated. This distributed design agent module is a software module running locally on the user's client, responsible for performing subsequent transaction processing, constraint verification, and network communication. The system assigns a unique session identifier to each collaborative design project. All distributed design agent modules using the same session identifier establish peer-to-peer communication connections through a network discovery mechanism, forming a collaborative design session network dedicated to that project.

[0071] Load the project model and constrained digital component assets. After successfully joining the session network, each distributed design agent module loads the BIM project model from the specified project data source. This loaded model contains the constrained digital component assets, which encapsulate the set of constraint rules, constructed in the preceding steps. Once loaded, each design agent maintains a complete, computationally viable copy of the model data in its local memory.

[0072] Initialize the distributed transaction log. To ensure the traceability and eventual consistency of all design changes, each distributed design agent module's transaction consistency module creates a local instance of the distributed transaction log. All distributed design agent modules participating in the same collaborative design session initialize their local distributed transaction logs to the same preset initial state. This initial state can be a genesis state without any transactions, or it can be synchronized to the state of the first distributed transaction log established in the session network, thus ensuring that all participants have a completely consistent starting point for their transaction history before performing any design operations.

[0073] After the distributed collaborative environment is initialized, the system enters a state of waiting for user operation. When the user performs a design operation, the system converts the user's graphical interaction into structured data that can be processed in subsequent steps through event listening and intent recognition.

[0074] The method for listening to and recognizing user actions may include the following sub-steps:

[0075] Register event handlers for the BIM software application programming interface. The distributed design agent module registers one or more event handlers with the software's event model via the API provided by the BIM software. These event handlers are configured to specifically listen for events related to geometric changes, such as component creation events, component movement events, and component geometry modification events.

[0076] Real-time capture of user operation event data. When a user performs a design operation in the BIM software's graphical interface and triggers the aforementioned registered event, the corresponding event handler is activated. This event handler captures the raw data related to the operation from the BIM software's event model. The captured dataset specifically includes: the user identifier performing the operation, the type of operation, the unique identifier of the directly operated main component, and the geometric state information of the main component before and after the operation.

[0077] Identify the context-dependent components of the operation. Operation events of the main component alone are insufficient to form a complete design intent. Therefore, the distributed design agent module immediately performs a localized spatial analysis after capturing the event data of the main component. This spatial analysis takes the geometric state information of the main component after the operation as input and queries the local model data copy for all secondary components that spatially interfere with or are adjacent to that geometric state. When a pipeline component is moved, the spatial analysis will identify the wall panel components that the pipeline passes through after the movement.

[0078] The distributed design agent module aggregates the captured raw event data with the identified context-related component information to form a structured design intent dataset. This dataset fully describes the intent of a user action, specifically including: user identifier, action type, main component identifier, proposed geometric state of the main component, and identifiers of one or more affected secondary components. This dataset serves as direct input for subsequent generation of preprocessed transactions.

[0079] After the user action event listening and intent recognition are completed, the distributed design agent module will aggregate the generated design intent dataset and convert it into a standardized preprocessed transaction. This preprocessed transaction is a structured data object used for transmission and processing in the subsequent verification and negotiation process of the system.

[0080] The data structure and generation logic for preprocessing transactions may include the following sub-steps:

[0081] Define the data structure for preprocessed transactions. A preprocessed transaction is denoted as... It is defined as a data structure containing the following fields:

[0082] Transaction identifier This identifier is a unique numeric or string value within the collaborative design session, used for referencing and tracking the transaction in subsequent processes. It can be generated when a transaction is created by combining a timestamp, user identifier, and random number.

[0083] User Identifier It is a unique identifier for the user who initiated the design operation.

[0084] Timestamp It records the precise time when the design operation was captured.

[0085] Operation type It is an enumeration value used to specify the specific type of design operation, such as component creation, component modification, or component deletion.

[0086] Target component set This is a set containing unique identifiers for all relevant components in this operation, specifically including the main components directly manipulated by the user and all identified context-related secondary components. This identification process can be accomplished by analyzing component adjacency relationships, family type dependencies, or preset logical association rules in the local BIM model data copy.

[0087] Proposed geometric state It is one or more geometric data objects that precisely describe the geometric state that the main component is expected to achieve in this operation.

[0088] Instantiate and populate the preprocessed transaction. The distributed design agent module instantiates the data in local memory according to the defined data structure. The agent then populates the object with data from the design intent dataset generated in the previous step, one by one. In the corresponding fields of the object, populate the user identifiers from the design intent dataset. The field, populated with the set of identifiers of the manipulated component and its associated components. Field.

[0089] After completing the above steps, a standardized encapsulation of the complete design intent is achieved. The object is now generated. At this point, the object serves as a temporary, unverified unit of data and will be passed to subsequent localized real-time verification steps for processing.

[0090] After the preprocessed transaction is generated, the distributed design agent module will immediately start the verification engine to perform local real-time verification of the transaction. The goal of this process is to quickly determine whether the user's design intent conforms to the basic constraints of the component itself.

[0091] The triggering and execution mechanism of the verification engine may include the following sub-steps:

[0092] Identify C-EMCAs affected by validation. When preprocessing transactions. After generation, the distributed design proxy module first... of The fields are parsed to extract the identifiers of all constrained digital component assets affected by the operation. If The description pertains to the operation of drilling holes in a wall panel; therefore, the wall panel's C-EMCA is the object affected by the verification. If If there are multiple C-EMCAs, the verification process will be performed independently for each C-EMCA.

[0093] This triggers the internal constraint verification function of the C-EMCA. For each affected C-EMCA, the distributed design agent module invokes the set of internal constraint rules encapsulated within that C-EMCA. This invocation operation will... Proposed geometric state As an input parameter, it is passed to C-EMCA's internal verification function. .Should The function encapsulates the logic of all internal constraint rules, and its execution result directly reflects... Does it satisfy the self-constraints of the C-EMCA?

[0094] The validation results are processed in real time and feedback is provided. The distributed design agent module receives... The result of the function execution.

[0095] like Returning a false value indicates If the internal constraints of C-EMCA are violated, the distributed design agent module will immediately terminate the preprocessed transaction. The transaction is marked as rejected. Simultaneously, the agent sends a notification to the user interface, providing immediate feedback to the user who initiated the action through both graphical and text prompts. The lifecycle of this pre-processed transaction terminates at this point.

[0096] like Returning a true value indicates If the internal constraints of C-EMCA are met, the distributed design agent module will... Mark it as having passed internal validation and pass it on to the subsequent external impact rule evaluation step.

[0097] The above mechanism ensures that users receive rapid and accurate feedback before submitting any potentially non-compliant design changes, effectively preventing the further spread of design schemes that do not conform to the specifications of individual components.

[0098] The detailed implementation and real-time feedback of the internal constraint function are explained below. This implementation is the core computational process for localized real-time verification.

[0099] Internal constraint functions This is a computational unit that logically aggregates all internal constraint rules within a constrained digital component asset. This function is executed when the verification engine is triggered. Its implementation may include the following sub-steps:

[0100] Performs a logical AND operation on the set of internal constraint rules. Internal constraint functions. The return value is defined as all individual constraint rule functions in the C-EMCA internal constraint rule set. The logical AND of the calculation results. Its logical relationship can be expressed as:

[0101] ;

[0102] in:

[0103] The final internal constraint verification result has a Boolean value.

[0104] Represents currently verified constrained digital component assets.

[0105] Represents preprocessed transactions The proposed geometry state that is passed in.

[0106] Represents the first in the set of constraint rules The computation function corresponding to a single internal constraint rule.

[0107] This represents the total number of internal constraint rules defined in this C-EMCA.

[0108] This logical relationship indicates that only when the proposed geometric state... Satisfy all When there are internal constraint rules, Only the final result is true.

[0109] Execute individual constraint rule functions sequentially. During the calculation... At that time, the distributed design agent module will execute each one sequentially or in parallel. Function. Each function with It takes as input and returns a boolean value. For example:

[0110] For the minimum boundary distance rule, the corresponding function will perform a geometric calculation to determine... Geometric boundaries and components The minimum distance between the geometric boundaries is calculated and compared with a threshold defined in the rule, and the comparison result is returned.

[0111] For rules that disable regions, the corresponding function will perform a spatial interference check to determine... Check whether the geometry overlaps with the geometry of any prohibited areas defined in the rules, and return the inspection results.

[0112] To improve computational efficiency, if any one of the following is executed sequentially... If the function returns a false value, the distributed design proxy module can interrupt all subsequent operations. The calculation of the function and its direct determination. The final result is false.

[0113] Generate and deliver real-time feedback information. The distributed design proxy module, based on... The final calculation result is used to perform an immediate feedback operation.

[0114] like If the result is false, it indicates that the verification failed, and the system will prevent the user from performing that operation in the BIM software; that is, the local model data will not be modified. Simultaneously, the system will remove the one or more factors that caused the verification failure. The rule information corresponding to the function is extracted and used as feedback content. It is then presented to the user who initiated the operation through the BIM software's user interface API in the form of text messages, component highlighting, or other visualization methods.

[0115] like If the result is true, it means that the localization verification has passed, and the system will allow the preprocessed transaction to enter the next processing stage. At this time, the user interface will not generate any blocking feedback.

[0116] Once the preprocessed transaction passes local real-time verification, the distributed design agent module will initiate the evaluation algorithm for external impact rules and trigger the decision-making process. This process is used to determine whether design changes effective at the component level may have an impact on other related components that requires negotiation.

[0117] The specific implementation of the evaluation algorithm and trigger determination for external influence rules may include the following sub-steps:

[0118] Retrieve and load the external influence rule set. The distributed design agent module performs this based on preprocessed transactions. target component set Retrieve and load the predefined set of external influence rules from the corresponding constrained digital component assets. This rule set contains multiple independent external impact rules, each defining a scenario requiring external negotiation. Each external impact rule predefines the scope or type of related components that need to be notified once it is triggered.

[0119] The triggering condition of each externality rule is iteratively evaluated. The distributed design agent module iterates through each rule in the loaded set of externality rules. For each rule, the agent executes its contained triggering condition function. This function preprocesses transactions. Proposed geometric state As input, a logical judgment is performed. The specific content of this logical judgment may include:

[0120] Threshold comparison of geometric parameters: Determine whether the maximum diameter of the proposed hole geometry exceeds the preset structural safety threshold.

[0121] Determining spatial relationships: Determine whether the proposed geometrical changes interfere with the predefined spatial volume inside the component that is marked as the main stress area.

[0122] Query and compare the status of components: Determine whether the proposed geometric changes will cause the ratio of the total area of ​​existing holes on the component to the cross-sectional area of ​​the component to exceed the preset limit.

[0123] The triggering condition function returns a boolean value after execution.

[0124] The system performs trigger determination and determines subsequent processes. The distributed design agent module collects the Boolean values ​​of the trigger condition functions for all external influence rules.

[0125] If all triggering condition functions return false, the system determines that this design change does not require external negotiation. This preprocessing transaction... It will be marked as not requiring dissemination and can proceed directly to the final adjudication step, and is usually approved directly.

[0126] If at least one of the triggering condition functions returns true, the system determines that this design change requires initiating an external negotiation process. This preprocessing transaction... These will be marked as needing to be propagated. Simultaneously, for each triggered external impact rule, the distributed design agent module will record the broadcast action information defined in that rule. This information includes the type of potential impact notification to be generated and the scope of target components that need to receive the notification. This information will serve as direct input for the next step of generating potential impact notifications.

[0127] If the evaluation result of the external impact rule indicates that external negotiation needs to be initiated, the distributed design agent module that initiated the operation will perform the generation, serialization, and broadcasting of the potential impact notification. This notification is a structured data packet used to transmit the negotiation request in the distributed network.

[0128] The specific implementation of this process may include the following sub-steps:

[0129] Define and instantiate the data structure for the potential impact notification. The potential impact notification is denoted as... It is defined as a data object containing the following fields:

[0130] Transaction identifier It is related to the preprocessed transaction that triggered the notification. The identifier is the same, used to associate the notification with the original design intent.

[0131] Source component identifier It is the unique identifier of the constrained digital component asset that triggers the external influence rule.

[0132] Source user identifier It is a unique identifier for the user who initiates the original design operation.

[0133] Type of impact This is an enumerated value or string that specifies the specific category of the potential impact defined by the triggered external impact rule. This category can specifically include: structural weakening impact, installation space interference impact, or process flow conflict impact.

[0134] Data payload It contains specific data needed by the recipient to assess the impact, including at least the original preprocessed transactions. Proposed geometric state .

[0135] The distributed design proxy module instantiates itself in local memory based on the information provided by the external influence rules triggered in the previous step. Create a data object and populate all the fields mentioned above.

[0136] Serialize the notification of potential impact. For transmission over the network, the distributed design agent module needs to serialize the notification in memory. The data object is converted into a continuous stream of bytes. This serialization process can... The object and all the data it contains are converted into a predefined, cross-platform data exchange format, either JSON or a binary byte stream format.

[0137] The broadcast protocol is executed to distribute the notification. The distributed design agent module determines which notification needs to be received based on the broadcast scope defined in the triggered external impact rule. The agent identifies all concrete component instances that satisfy the scope definition by querying a local copy of the model data. Subsequently, the agent retrieves the network addresses of other distributed design agent modules responsible for managing these target component instances from the member directory that maintains the network node state. Finally, the agent generates a serialized byte stream and sends it asynchronously to all identified target network addresses via a P2P communication protocol. After sending, the distributed design agent module that initiated the operation enters a state awaiting negotiation responses.

[0138] When the non-initiator's distributed design agent module listens for a potential impact notification on its network port When incoming data arrives, the proxy will initiate the negotiation logic and response generation mechanism of the receiving proxy. This mechanism is a key step in realizing distributed, peer-to-peer negotiation.

[0139] The specific implementation of this process may include the following sub-steps:

[0140] Receive and deserialize potential impact notifications. The distributed design agent module receives notifications from its network communication module on behalf of... The agent first verifies the integrity and format of the byte stream, then deserializes it and reconstructs it in local memory. Data object.

[0141] Perform context-dependent negotiation evaluation. The receiving agent, based on... The information in the data object is used to perform a localized impact assessment. This assessment is based on... Data payload in and types of impact As input, and combined with the current state and constraint rules of the constrained digital component assets managed by the receiving agent, calculations are performed. The specific logic of this evaluation is based on... Different types:

[0142] If the impact type is structural weakening impact, the receiving agent will invoke the structural safety-related constraint rules in the C-EMCA it manages to calculate... Determine the spatial relationship between the system and its critical stress-bearing areas, and determine whether this relationship meets the safety redundancy requirements.

[0143] If the impact type is installation space interference, the receiving agent will perform a geometric interference check to determine... Does it encroach on the installation or maintenance space reserved by its own C-EMCA?

[0144] If the impact type is a process flow conflict impact, the receiving agent will query the construction or installation sequence information recorded in its C-EMCA to determine the cause. Does the design change it represents logically conflict with the established process flow?

[0145] Generate a negotiation response. Based on the calculation results of the negotiation evaluation, the receiving agent generates a negotiation response. The negotiation response is denoted as... It is defined as a data structure containing the following fields:

[0146] Transaction identifier Its relationship with the received The identifiers are the same, and are used for attribution association of the response.

[0147] Response component identifier This is the unique identifier of C-EMCA that is conducting this consultation assessment.

[0148] Response status The value is an enumeration and can specifically be: approved, indicating that the design change is feasible from the perspective of this component; rejected, indicating that the design change has an unacceptable conflict; or conditional approval, indicating that the change can be accepted provided that specific modification suggestions are met.

[0149] Response data This is an optional field. When the response status is Reject, this field may contain a description of the specific constraint rule that caused the rejection; when the response status is Conditional Approval, this field may contain one or more modification suggestions that suggest moving the hole to a location that has less impact on itself.

[0150] Serialize and send back the negotiated response. Receive the response generated by the proxy. The data object is serialized and converted into a byte stream. Then, the proxy sends the serialized response byte stream back to the client via a P2P communication network. The sender is the network address of the distributed design agent module that initiated the original design operation. Once the transmission is complete, the receiving agent's negotiation task ends.

[0151] Once the distributed design agent module that initiated the transaction broadcasts a notification of potential impact, the process enters the phase of collecting negotiation responses and handling timeouts. This mechanism ensures the convergence and robustness of the negotiation process, allowing it to continue even in the event of network latency or unresponsive participants.

[0152] The specific implementation of this process may include the following sub-steps:

[0153] Initialize the response collection state and start the timeout timer. Send the final potential impact notification. Then, the distributed design agent module immediately performs the following operations:

[0154] According to what has been sent Quantity, determining the total number of expected responses to be awaited during this negotiation. .

[0155] Transaction identifier for this negotiation Create a local memory instance to store the negotiation response. An empty set.

[0156] Start a countdown timer for a preset duration. This duration is the timeout threshold. , is a configurable system parameter used to define the maximum waiting time for a negotiation response.

[0157] Listen for and process incoming negotiation responses. The distributed design agent module continuously listens on its network communication port. When it receives an incoming network data packet, the agent deserializes it.

[0158] If the data packet can be successfully parsed into a negotiation response Data objects, and their If it matches the currently waiting transaction identifier, then... It is considered a valid response.

[0159] The valid response is added to the response set.

[0160] The system checks whether the number of responses collected has reached the expected total number of responses. If the condition is met, it means that all participants have responded, and the system will automatically stop the timeout timer and immediately proceed to the final adjudication step.

[0161] Perform timeout handling. If the timeout timer expires during the listening process, and the number of collected responses is still less than [a certain number], then [the timeout will be handled accordingly]. If this happens, the timeout handling mechanism will be triggered.

[0162] The system considers all target components that have not yet received a response as having a default rejection of this design change.

[0163] For each unresponsive target component, the distributed design agent module generates and adds a response status to its local response set. Record of the negotiation response to rejection.

[0164] After the above additions are completed, the response set is considered complete, containing the explicit or implicit statements of all negotiation participants. This pre-processed transaction is then passed to the final adjudication step for further processing.

[0165] After the collection of negotiation responses is completed, the distributed design agent module that initiated the transaction will execute the final decision function. The goal of this function is to comprehensively evaluate all collected negotiation responses based on predefined, deterministic logic, thereby determining the final outcome of the original preprocessed transaction.

[0166] The implementation logic of the final decision function may specifically include the following sub-steps:

[0167] Define the final decision-making rules. These rules are designed as a hierarchical set of logical conditions to handle different combinations of negotiated responses. This rule set prioritizes ensuring the system's design consistency and security.

[0168] The veto priority rule states that, in the collected response set, as long as there is at least one negotiated response, the veto will be rejected. response status If the decision is rejected, the final decision for the entire preprocessing transaction is determined to be disapproval.

[0169] Conditional aggregation rule: This rule stipulates that, provided the veto priority rule is not satisfied, if there is at least one negotiated response in the response set... response status If the approval is conditional, the final decision for the entire preprocessing transaction is determined to be pending modification.

[0170] Unanimous agreement rule: This rule stipulates that only all negotiated responses in the response set are considered valid. response status Only when all conditions are met is the final decision of the entire preprocessing transaction determined as approved.

[0171] Perform the decision calculation. The distributed design agent module will traverse the collected set of negotiation responses and calculate them strictly according to the order of the evaluation rules. The agent first checks if there is a response with a rejection status. If so, it immediately stops subsequent checks and outputs a decision of disapproval. If not, it continues to check if there is a response with a conditional approval status. If so, it outputs a decision to be modified. If neither of the above two conditions is met, it directly outputs a decision of approval.

[0172] The decision-making process determines the outcome and triggers subsequent actions. Based on the final decision, the distributed design agent module executes the corresponding follow-up actions.

[0173] If the ruling is negative, the agent will aggregate the response data from all negotiation responses with a rejection status. The system then displays this information, including the reasons for rejection, to the user who initiated the operation via the user interface. The lifecycle of this preprocessing transaction ends here, and the user's local model remains unchanged.

[0174] If the ruling is pending modification, the agent will aggregate the response data from all approved negotiated responses with a conditional status. This information, including suggested modifications, is then fed back to the user, prompting them to adjust the original design intent. The lifecycle of this preprocessing transaction also ends at this point.

[0175] If the ruling is approval, it means that the design operation has no objection from all relevant parties, and the agent will proceed to the final transaction construction step.

[0176] If and only if the final decision function results in approval, the distributed design agent module that initiated the transaction will execute the final transaction construction and metadata appending steps. The goal of this step is to generate the final data unit containing complete negotiation proofs, which can be used for subsequent distributed ledger recording.

[0177] The specific implementation of this process may include the following sub-steps:

[0178] Define the data structure for a final transaction. A final transaction is denoted as... It is in the preprocessing of transactions This data structure, derived from the existing structure, specifically includes the following fields:

[0179] Inherited from All fields, including: Transaction Identifier User identifier timestamp Operation type Target component set and proposed geometric states .

[0180] Newly added negotiation metadata field This field is specifically used to store proof of the complete negotiation process that the firm went through in this transaction.

[0181] Instantiate the final transaction and migrate the underlying data. The distributed design agent module is instantiated in local memory. The object. Subsequently, the agent will process the approved pre-processed transaction. All data is completely copied to... The corresponding field in the object.

[0182] Additional negotiation metadata. The distributed design agent module will collect all negotiation responses related to this transaction from the preceding steps. The complete set, as a whole, is attached to Object negotiation metadata field The collection contains the response status and data returned by each notified participant, thus providing a traceable, auditable, and non-repudiable chain of evidence for the approval of this design change.

[0183] After completing the above steps, The data object is now complete. This object not only encapsulates the finally approved design changes but also binds them to the results of the distributed negotiation through additional negotiation metadata. The object, as a self-contained, verified data packet, will be passed to the transaction consistency module for final synchronization of state throughout the collaborative design network.

[0184] When the final transaction Once successfully constructed, the transaction consistency module of the distributed design agent module that initiated the transaction will start the distributed transaction log consistency appending protocol. The goal of this protocol is to ensure that the distributed design agents of all participants in the network append the transaction log in exactly the same and deterministic order. Each transaction is recorded in its local distributed transaction log, thus enabling the synchronized evolution of the entire collaborative design environment state. Functionally, this protocol implements a simplified two-phase commit or a variant thereof, designed to ensure the atomicity of transaction appends.

[0185] This distributed transaction log It is an append-only ordered data structure maintained locally by each distributed design agent, which can be represented as a sequence of final transactions:

[0186] ;

[0187] in, This represents the total number of transactions currently recorded. A concrete implementation of the consistency append protocol may include the following sub-steps:

[0188] Proposal phase. The distributed design agent module that initiates the transaction constructs the final transaction locally. The broadcast, via a P2P communication network, is sent to all other distributed design agents in the collaborative design session. This broadcast operation is equivalent to adding a proposal in the protocol, requesting all participants to submit the proposal. As its local The first in One entry.

[0189] The pre-write phase. Each node in the network that receives this... The distributed design of the broadcast proxy first performs a verification of the transaction. The verification includes checking... The integrity of the data structure, and the confirmation of its transaction identifier. The uniqueness of the information. After successful verification, the receiving agent will... It is appended to the end of its local log and marked as pending, but not immediately regarded as a final state that has taken effect.

[0190] Confirmation Phase. After completing the write-ahead operation, each receiving agent sends a write-ahead acknowledgment message to the source agent that initiated the broadcast. This acknowledgment message indicates that the receiving agent is ready to commit the transaction.

[0191] The decision submission phase. The source agent is responsible for collecting confirmation messages from all other agents. Once it has collected confirmation messages from all expected participants, it considers the append operation to have reached consensus across the network. Subsequently, the source agent broadcasts the commit instruction to all distributed design agents in the network. This instruction is accompanied by a specific transaction identifier. Related.

[0192] Submission execution phase. All distributed design agents that receive the submission command check their local logs for the corresponding... The one that is pending submission The entry has been officially updated to a submitted status. At this point, the entry... It becomes an immutable and permanent record in the logs of all participants. This consistent append protocol ensures the atomicity of transactions, meaning that a transaction is either recorded by all participants or not recorded at all, thus avoiding inconsistencies in data state.

[0193] When the final transaction Once consistently appended to the distributed transaction log, each distributed design agent module in the network must perform an atomic update of the client model to apply the design changes represented by the transaction to its locally maintained copy of the model data.

[0194] The specific implementation of this process may include the following sub-steps:

[0195] Trigger a local model update. This occurs when the distributed design agent module updates its local distributed transaction log. In the middle, When the status changes from pending submission to submitted, this event will act as a trigger to initiate the update process for the local BIM model data.

[0196] Perform atomic geometry operations. The distributed design agent module retrieves data from the submitted... In the process, the proposed geometric state is analyzed. and target component set Subsequently, the agent performs atomic model modification operations through the BIM software's application programming interface. This operation ensures... All geometric changes described herein are applied completely as indivisible units. On the corresponding component. If the operation fails for any reason during the application process, the entire change will be completely rolled back, and the local model will be restored to the state before the operation was performed, thus ensuring the internal consistency of the local model data at any time.

[0197] Achieve state convergence and resolve conflicts. This is because the consistency appending protocol ensures that all distributed design agents in the network have byte-level identical and perfectly ordered distributed transaction logs. Furthermore, each agent executes transactions in the log in the same order, thus ensuring deterministic convergence of the local model state for all clients. This invention transforms the concurrent operation conflicts that require post-processing in traditional collaborative designs into a competition for the right to add weight to a single transaction, resolved beforehand, through a negotiation and consensus mechanism prior to transaction commit. Once a transaction is accepted by the consensus protocol and recorded in the log, it becomes part of the sole legitimate history of the entire system's evolution. Therefore, during the model update phase, no conflicts requiring additional logical processing arise; this step essentially involves a localized, deterministic replay of the already agreed-upon global state.

[0198] Refresh the user view. After the local model data has been successfully and atomically updated, the distributed design agent module will invoke the BIM software's interface refresh command, allowing the user to instantly observe the model changes resulting from the transaction in the graphical interface. If this update was initiated by another user, that user will see their collaborator's design results applied conflict-free to their own design environment.

[0199] Please see the appendix Figure 1 A BIM collaborative design system for pre-drilled holes in double-layer foamed ceramic wall panels, comprising:

[0200] The preprocessing transaction generation module is used to generate a preprocessing transaction containing the proposed geometry state after receiving the hole reservation design operation;

[0201] The localization verification module is used to perform localized real-time verification on preprocessed transactions based on the internal constraint rules of the source-constrained digital component assets.

[0202] The negotiation initiation module is used to determine whether distributed negotiation needs to be initiated based on external impact rules after local real-time verification is passed, and to generate and broadcast potential impact notifications when necessary.

[0203] The adjudication and response management module is used to collect negotiation responses returned by other distributed design agent modules and execute the final adjudication based on preset rules;

[0204] The transaction consistency module is used to construct the final transaction when the decision result is approval, and to ensure that the final transaction is synchronously appended to the distributed transaction logs of each participant in the network through the consistency appending protocol.

[0205] The model synchronization module is used to atomically update local model data based on the contents of the distributed transaction log.

[0206] The system in this embodiment can be used to execute the above method embodiments, and its principle and technical effect are similar, so they will not be described again here.

Claims

1. A BIM collaborative design method for pre-reserved holes in double-layer foamed ceramic wall panels, characterized in that, Includes the following steps: S1. Upon receiving a hole reservation design operation for a source-constrained digital component asset, generate a preprocessed transaction containing the proposed geometry. S2. Based on the internal constraint rules of the source-constrained digital component assets, perform localized real-time verification on the preprocessed transaction; S3. After the localized real-time verification is passed, based on the external influence rules of the source-constrained digital component assets, determine whether the preprocessing transaction needs to initiate distributed negotiation. S4. If distributed negotiation needs to be initiated, generate and broadcast a potential impact notification to the distributed design agent of the target constrained digital component asset, and collect the negotiation responses returned by each of the distributed design agents. S5. Based on the collected negotiation responses, execute a final ruling to determine the outcome of the pre-processed transaction; S6. If the final decision is to approve, then a final transaction is constructed and appended to the distributed transaction logs of each participant in the network through a consistency appending protocol. S7. Each participating party updates its local model data in principle based on the final transaction committed in its distributed transaction log.

2. The BIM collaborative design method for pre-reserved holes in a double-layer foamed ceramic wall panel according to claim 1, characterized in that, The steps for performing localized real-time verification include: Execute the internal constraint function, the return value of which is the logical AND of the calculation results of all individual internal constraint rule functions in the set of internal constraint rules of the source constrained digital component asset.

3. The BIM collaborative design method for pre-reserved holes in a double-layer foamed ceramic wall panel according to claim 1, characterized in that, The step of determining whether the preprocessing transaction needs to initiate distributed negotiation includes: Iteratively evaluate each external impact rule in the set of external impact rules for the source-constrained digital component assets; determine that distributed negotiation needs to be initiated if and only if the triggering condition of at least one of the external impact rules is met.

4. The BIM collaborative design method for pre-reserved holes in a double-layer foamed ceramic wall panel according to claim 3, characterized in that, The potential impact notification is a structured data object that includes: a transaction identifier associated with the preprocessing transaction, an impact type, and a data payload containing the proposed geometry.

5. The BIM collaborative design method for pre-reserved holes in a double-layer foamed ceramic wall panel according to claim 1, characterized in that, The negotiation response is a structured data object that includes a response status; the value of the response status is selected from: approval, rejection, or conditional approval.

6. The BIM collaborative design method for pre-reserved holes in a double-layer foamed ceramic wall panel according to claim 1, characterized in that, The step of collecting negotiation responses also includes a timeout handling mechanism: Start a timeout timer after broadcasting the potential impact notification; If no negotiation response is received from the distributed design agent of a target constrained digital component asset within the preset timeout threshold, a negotiation response with a rejection status is generated for that target constrained digital component asset.

7. The BIM collaborative design method for pre-reserved holes in a double-layer foamed ceramic wall panel according to claim 5, characterized in that, The steps for executing the final ruling follow the following hierarchical evaluation rules: If the response status of any of the collected negotiation responses is rejection, then the processing result of the preprocessed transaction is disapproval. If there is no negotiation response with a rejection status, but there is at least one negotiation response with a conditional approval status, then the outcome of the preprocessed transaction is pending modification. If all collected negotiation responses are approved, then the processing result of the preprocessed transaction is approved.

8. The BIM collaborative design method for pre-reserved holes in a double-layer foamed ceramic wall panel according to claim 1, characterized in that, The steps for constructing the final transaction include: The data from the preprocessed transaction is aggregated with the negotiation metadata field containing all collected negotiation responses to form the final transaction.

9. The BIM collaborative design method for pre-reserved holes in a double-layer foamed ceramic wall panel according to claim 1, characterized in that, The consensus append protocol includes: Proposal Phase: In this phase, the initiator broadcasts the final transaction. Write-ahead phase: In this phase, the receiver verifies the final transaction and writes it to the local distributed transaction log in a pending-commit state; Submission Execution Phase: In this phase, after the initiator collects confirmations from all recipients, it broadcasts a submission instruction, and all participants update the status of the final transaction to "submitted".

10. A BIM collaborative design system for pre-drilled holes in double-layer foamed ceramic wall panels, and a BIM collaborative design method for pre-drilled holes in double-layer foamed ceramic wall panels according to any one of claims 1-9, characterized in that, include: The preprocessing transaction generation module is used to generate a preprocessing transaction containing the proposed geometry state after receiving the hole reservation design operation; The localization verification module is used to perform localized real-time verification on the preprocessed transaction based on the internal constraint rules of the source-constrained digital component assets. The negotiation initiation module is used to determine whether distributed negotiation needs to be initiated based on external impact rules after the localized real-time verification is passed, and to generate and broadcast potential impact notifications when necessary. The adjudication and response management module is used to collect negotiation responses returned by other distributed design agent modules and execute the final adjudication based on preset rules; The transaction consistency module is used to construct a final transaction when the decision result is approval, and to ensure that the final transaction is synchronously appended to the distributed transaction logs of each participant in the network through a consistency appending protocol. The model synchronization module is used to update the local model data in principle based on the content of the distributed transaction log.

Images