Construction method and system of intelligent fabricated building
Patent Information
- Application Number
- CN202611529708.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-30
- Publication Date
- 2026-11-03
AI Technical Summary
Traditional information collaboration systems struggle to track the state transitions of components across different dimensions in prefabricated buildings, cannot effectively handle concurrent writes, leading to logical contradictions in data state, affecting construction safety and continuity, and consuming significant network bandwidth and computing resources for synchronization mechanisms.
A unique identifier is set for prefabricated building components, a multi-dimensional state vector clock and a topological constraint adjacency graph are constructed, concurrent versions are identified through the multi-dimensional state vector clock, and an associative conflict entropy value is generated by combining the topological constraint weights. A write permission threshold is set, and Merkle root hashing is used to achieve targeted incremental synchronization of data in specific dimensions.
It improves the accuracy and data consistency of multi-node collaborative operation, reduces the risk of concurrent conflicts, and enhances the data flow and synchronization efficiency of the prefabricated building life cycle management system.
Smart Images

Figure CN123030684A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of construction, and in particular relates to a method and system for constructing intelligent prefabricated buildings. Background Technology
[0002] With the rapid development of industrialized construction, prefabricated buildings have been widely used due to their environmental advantages. Throughout their lifecycle, components undergo design, production, logistics, and installation, with status data frequently flowing between multiple participating nodes. Due to the large number of components and their topological constraints, a distributed collaborative network is formed among the participants. In actual operations, different nodes may simultaneously initiate status updates for the same component or related component groups, leading to high-concurrency writes. Traditional information collaboration systems struggle to track the state transition trajectories of components across different dimensions and typically treat changes to individual components in isolation when handling concurrent writes, failing to incorporate component topological constraints into the overall assembly logic analysis. This prevents the conversion of topological relationships into data conflict weights, making it difficult for the system to assess the severity of conflicts when facing concurrent versions. This can easily lead to logical contradictions in the data states between distributed nodes, affecting the safety and continuity of construction.
[0003] In a distributed environment, traditional algorithms often employ static consistency thresholds, which struggle to balance the critical differences in component state updates across various dimensions and the business weights of replica nodes. Fixed write permission policies fail to provide sufficient consistency guarantees under strong constraints and may cause unnecessary communication congestion during ordinary state updates, failing to effectively balance system availability and strong consistency. Prefabricated building component data exhibits multi-dimensional and complex characteristics, with different participating nodes typically only needing to synchronize data relevant to their own business at specific stages. Existing distributed replica synchronization mechanisms largely rely on data structure traversal or indiscriminate hash tree comparisons, lacking multi-dimensional granularity. This makes it difficult to locate and target data changes in specific dimensions, easily consuming significant network bandwidth and computing resources, thus hindering efficient incremental synchronization of massive component data across multiple nodes. Summary of the Invention
[0004] According to one aspect of the present invention, a method for constructing an intelligent prefabricated building is proposed to solve the problem that existing methods cannot locate and target updates for data changes in specific dimensions, comprising the following steps: A unique identifier is assigned as the key to each prefabricated building component. A component data object containing component attributes, a multidimensional state vector clock, and a topological constraint adjacency graph is constructed as the value. The multidimensional state vector clock is constructed, which consists of node identifiers and evolutionary state vectors. It tracks the state transitions of the component in four dimensions: design, production, logistics, and installation. When a node initiates a write request for a specific dimension to the target component, the concurrent version is identified based on the multidimensional state vector clock. The topological constraint weights are obtained by traversing the associated components using the adjacency graph. The vector clock difference between the version to be written of the target component and the current version of each replica in the specific dimension is calculated. The correlation conflict entropy value is generated by combining the topological constraint weights. Based on the correlation conflict entropy value, a write permission threshold W is set that is positively correlated with it. Based on the clock proximity of each replica node in the corresponding dimension of the multidimensional state vector clock, the critical weight of the node is calculated. When the cumulative weight of the set of nodes that confirm the write request is not less than the write permission threshold W, the write operation is permitted. Components with constraints are set as an assembly set, and dimension-specific Merkle root hashes are generated in four dimensions. The Merkle root hashes of the four dimensions are combined into a composite digest signature. Nodes achieve targeted incremental synchronization of data in specific dimensions by first comparing the composite digest signature and then comparing the Merkle root hashes of each dimension as needed.
[0005] Optionally, the construction of the multidimensional state vector clock, which consists of node identifiers and evolutionary state vectors, includes: Obtain the node-specific identifier of the distributed nodes; Collect the cumulative values of the state transition of prefabricated building components in various engineering dimensions such as design, production, logistics, and installation, and generate a numerical component evolution state vector; Using the node's independent identifier as the key and the numerical component evolution state vector as the value, construct a vector clock key-value pair; The vector clock key-value pairs are stored in the state cache queue as the basic record of the multidimensional state vector clock.
[0006] Optionally, calculating the vector clock difference between the version of the target component to be written and the current version of each replica along the specific dimension includes: Extract the vector clock record of the version to be written of the target component in the specific dimension, and the vector clock record of the current version of each replica node in the specific dimension; Align the vector clock records of the version to be written with the current version of each replica according to the node identifier, and fill in the specific dimension scalar values corresponding to the missing node identifiers according to the preset initial values. Calculate the difference between the aligned scalar values of a specific dimension, and summarize the difference values corresponding to the same replica node to obtain the clock difference measure of the replica node in the specific dimension. The clock difference measure corresponding to each replica node is stored in a temporary queue.
[0007] Optionally, the step of calculating and generating the correlation conflict entropy value by combining the topological constraint weights includes: The specific dimension clock difference measure corresponding to each replica node in the temporary queue is summarized to obtain the total system difference value; Calculate the average replica conflict metric based on the total system discrepancy value and the number of replica nodes storing the target component replicas; The average replica conflict metric is fused with the topological constraint weight to obtain the correlation conflict entropy value. The associated conflict entropy value is saved as the criterion for subsequently setting the write permission threshold.
[0008] Optionally, setting a write permission threshold W that is positively correlated with the correlation conflict entropy value includes: Based on the correlation conflict entropy value and the preset weight mapping parameters, a conflict penalty increment is generated that is on the same weight scale as the node critical weight; Obtain the critical weights of each replica node storing the target component replica, and summarize the critical weights to obtain the total system weight; A basic threshold that is strictly greater than half of the total system weight is generated based on the total system weight. The candidate write permission threshold is obtained by superimposing the base threshold and the conflict penalty increment. The candidate write permission threshold is constrained by an upper limit based on the total weight of the system to obtain the current write permission threshold W of the target component.
[0009] Optionally, the step of setting the components with constraints as an assembly set, generating dimension-specific Merkle root hashes in four dimensions, and combining the four Merkle root hashes into a composite digest signature includes: Extract the dimensional status data and corresponding log data streams of the component assembly set in the four dimensions of design, production, logistics and installation respectively; Based on the dimensional state data and corresponding log data streams of each dimension, four independent Merkle root hashes are generated respectively; The Merkle root hashes of the four independent dimensions are combined in a preset dimensional order, and a second hash operation is performed on the combination result to generate a composite digest signature of the component assembly set. The composite digest signature is stored in the target verification pool for data synchronization and comparison between nodes.
[0010] According to a second aspect of the present invention, a construction system for intelligent prefabricated buildings is provided, comprising the following modules: The module is used to assign a unique identifier to prefabricated building components as the key, construct a component data object containing component attributes, a multidimensional state vector clock, and a topological constraint adjacency graph as the value, and construct the multidimensional state vector clock, which consists of node identifiers and evolutionary state vectors, to track the state transitions of components in four dimensions: design, production, logistics, and installation. When a node initiates a write request for a specific dimension of the target component, the concurrent version is identified based on the multidimensional state vector clock, the topological constraint weights are obtained by traversing the associated components using the adjacency graph, the vector clock difference between the target component's version to be written and the current version of each replica in the specific dimension is calculated, and the correlation conflict entropy value is generated by combining the topological constraint weights. The calculation module is used to set a write permission threshold W that is positively correlated with the correlation conflict entropy value, calculate the critical weight of each node based on the clock proximity of each replica node in the corresponding dimension of the multidimensional state vector clock, and permit the write operation when the cumulative weight of the set of nodes confirming the write request is not less than the write permission threshold W. The generation module is used to set components with constraints as an assembly set, generate dimension-specific Merkle root hashes in four dimensions, and combine the Merkle root hashes of the four dimensions into a composite digest signature. Nodes achieve targeted incremental synchronization of data in specific dimensions by first comparing the composite digest signature and then comparing the Merkle root hashes of each dimension as needed.
[0011] Preferably, the construction of the multidimensional state vector clock, which consists of node identifiers and evolutionary state vectors, includes: Obtain the node-specific identifier of the distributed nodes; Collect the cumulative values of the state transition of prefabricated building components in various engineering dimensions such as design, production, logistics, and installation, and generate a numerical component evolution state vector; Using the node's independent identifier as the key and the numerical component evolution state vector as the value, construct a vector clock key-value pair; The vector clock key-value pairs are stored in the state cache queue as the basic record of the multidimensional state vector clock.
[0012] Preferably, calculating the vector clock difference between the version of the target component to be written and the current version of each replica along the specific dimension includes: Extract the vector clock record of the version to be written of the target component in the specific dimension, and the vector clock record of the current version of each replica node in the specific dimension; Align the vector clock records of the version to be written with the current version of each replica according to the node identifier, and fill in the specific dimension scalar values corresponding to the missing node identifiers according to the preset initial values. Calculate the difference between the aligned scalar values of a specific dimension, and summarize the difference values corresponding to the same replica node to obtain the clock difference measure of the replica node in the specific dimension. The clock difference measure corresponding to each replica node is stored in a temporary queue.
[0013] Preferably, the step of calculating and generating the correlation conflict entropy value by combining the topological constraint weights includes: The specific dimension clock difference measure corresponding to each replica node in the temporary queue is summarized to obtain the total system difference value; Calculate the average replica conflict metric based on the total system discrepancy value and the number of replica nodes storing the target component replicas; The average replica conflict metric is fused with the topological constraint weight to obtain the correlation conflict entropy value. The associated conflict entropy value is saved as the criterion for subsequently setting the write permission threshold.
[0014] Preferably, setting a write permission threshold W that is positively correlated with the correlation conflict entropy value includes: Based on the correlation conflict entropy value and the preset weight mapping parameters, a conflict penalty increment is generated that is on the same weight scale as the node critical weight; Obtain the critical weights of each replica node storing the target component replica, and summarize the critical weights to obtain the total system weight; A basic threshold that is strictly greater than half of the total system weight is generated based on the total system weight. The candidate write permission threshold is obtained by superimposing the base threshold and the conflict penalty increment. The candidate write permission threshold is constrained by an upper limit based on the total weight of the system to obtain the current write permission threshold W of the target component.
[0015] Preferably, the step of setting the components with constraints as an assembly set, generating dimension-specific Merkle root hashes in four dimensions, and combining the four Merkle root hashes into a composite digest signature includes: Extract the dimensional status data and corresponding log data streams of the component assembly set in the four dimensions of design, production, logistics and installation respectively; Based on the dimensional state data and corresponding log data streams of each dimension, four independent Merkle root hashes are generated respectively; The Merkle root hashes of the four independent dimensions are combined in a preset dimensional order, and a second hash operation is performed on the combination result to generate a composite digest signature of the component assembly set. The composite digest signature is stored in the target verification pool for data synchronization and comparison between nodes.
[0016] This invention constructs data objects for prefabricated building components, including multi-dimensional state vector clocks and topological constraint adjacency graphs, to record the state evolution of components across design, production, logistics, and installation dimensions. When processing concurrent write requests, it generates an associative conflict entropy value by combining topological constraint weights with the differences in multi-dimensional vector clocks, and sets a write permission threshold accordingly, introducing node criticality weights calculated based on clock recentity. By combining write permission conditions with conflict severity and node data validity, it improves the accuracy and data consistency of multi-node collaborative operations and reduces the risk of concurrent conflicts. A multi-dimensional Merkle tree and composite digest signature structure are constructed for the prefabricated building assembly, enabling nodes to quickly locate data changes in specific dimensions through hierarchical comparison, achieving targeted incremental synchronization, reducing redundant data transmission, and improving the data flow and synchronization efficiency of the prefabricated building lifecycle management system. Attached Figure Description
[0017] Figure 1 A flowchart of the first embodiment; Figure 2 A comparison chart of vector clock differences between different replica nodes; Figure 3 A comparison chart of conflict measures, topological weights, and conflict entropy values for different types of prefabricated components. Detailed Implementation
[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0019] In the first embodiment, the present invention proposes a method for constructing an intelligent prefabricated building, such as... Figure 1 It includes the following steps: S1. Assign a unique identifier as the key to the prefabricated building component, and construct a component data object containing component attributes, a multidimensional state vector clock, and a topological constraint adjacency graph as the value. Construct the multidimensional state vector clock, which consists of node identifiers and evolutionary state vectors, to track the state transitions of the component in four dimensions: design, production, logistics, and installation. When a node initiates a write request for a specific dimension to the target component, identify the concurrent version based on the multidimensional state vector clock, traverse the associated components using the adjacency graph to obtain the topological constraint weights, calculate the vector clock difference between the target component's version to be written and the current version of each replica in the specific dimension, and calculate and generate the correlation conflict entropy value based on the topological constraint weights.
[0020] For each prefabricated building component, a unique component identifier is generated as the key, and a component data object structure is constructed as the value. This structure contains component attribute fields recording dimensions and material types, a multidimensional state vector clock field recording node-specific identifiers and four-dimensional integer arrays, and a directed weighted adjacency graph field representing the topological constraints between components. The multidimensional state vector clock data structure is a mapping from node identifiers to four-dimensional integer arrays, with each node identifier corresponding to an evolutionary state vector containing four engineering dimensions: design, production, logistics, and installation. When initializing the multidimensional state vector clock, the initial values of the design, production, logistics, and installation dimensions of the four-dimensional integer array are all set to 0. When a node initiates a write request for a specific dimension, the current multidimensional state vector clock of the target component is retrieved using a key-value index.
[0021] Version relationship identification is based on an overall vector clock execution across four dimensions: design, production, logistics, and installation. The correlation conflict entropy value is calculated only for the specific dimension corresponding to the current write request. The vector of the version to be written is compared with the current vectors of each replica. If there is no unidirectional inclusion relationship (i.e., the value of the version to be written is greater than the current replica version in at least one dimension and less than the current replica version in at least another dimension), it is identified as a concurrent version. If the values in all dimensions are completely equal, it is considered a duplicate write request. If the version to be written is not less than the current replica version in all dimensions and is greater than the current replica version in at least one dimension, it is considered a version that can be sequentially advanced. If the version to be written is not greater than the current replica version in all dimensions and is less than the current replica version in at least one dimension, it is considered an older version.
[0022] The topological constraint adjacency graph of the target component is traversed within a preset topological search order or a preset topological constraint radius. When both conditions are set simultaneously, the associated edges that satisfy both conditions are considered the valid traversal range. The edge weights of the valid associated edges are extracted to form an edge weight set, and the maximum value is selected as the topological constraint weight for this conflict calculation. When there are no valid associated edges, Set to the default value of 1.0. For a specific dimension corresponding to this write request, calculate the state deviation between the version to be written and the current version of each replica, and sum the state deviations corresponding to the same replica node to obtain the specific dimension clock difference measure of that replica node.
[0023] The clock difference metrics of all replica nodes in a specific dimension are aggregated and the average replica conflict metric is calculated, then compared with the topology constraint weights. A multiplication operation is performed to generate an associative conflict entropy value. This associative conflict entropy value characterizes the combined conflict impact of replica state deviation and component topological constraint strength, and is not limited to the result calculated using the Shannon entropy formula. A comparison of vector clock difference measures for different replica nodes is provided. Figure 2 As shown.
[0024] When a duplicate write request is identified, an idempotent success response is returned and the status is not updated repeatedly; when a version that can be sequentially advanced is identified, the write permission threshold determination process is initiated; when a concurrent version is identified, the correlation conflict entropy value calculation and dynamic write permission threshold determination process is initiated; when an old version is identified, the current write is rejected or the process is initiated to synchronize the replica, and the old version is not allowed to directly overwrite the current version.
[0025] In an optional embodiment, the construction of the multidimensional state vector clock, which consists of node identifiers and evolutionary state vectors, includes: Obtain the node-specific identifier of the distributed nodes; Collect the cumulative values of the state transition of prefabricated building components in various engineering dimensions such as design, production, logistics, and installation, and generate a numerical component evolution state vector; Using the node's independent identifier as the key and the numerical component evolution state vector as the value, construct a vector clock key-value pair; The vector clock key-value pairs are stored in the state cache queue as the basic record of the multidimensional state vector clock.
[0026] The MAC addresses of the network interface cards (NICs) hosting each distributed node server are read, for example, 00:1A:2B:3C:4D:5E. To remove format differences between different operating systems, regular expressions are used to filter out colons and convert the string to all uppercase 001A2B3C4D5E. This string is then stored as a globally unique node identifier (NodeID) for long-term storage. In other implementations, node certificate numbers, device serial numbers, or system-assigned node UUIDs can also be used as node identifiers to adapt to multi-NIC, virtualization, or cloud deployment environments. In the four core engineering dimensions of prefabricated buildings—design, production, logistics, and installation—the workflow engine's approval log records are monitored using data tracking technology. The number of times a specific component's business approval process is completed is extracted in an incremental time-series manner and used as the cumulative value of the process steps. For example, in the production dimension, after a precast wall panel completes four state transitions (reinforcement binding, concrete pouring, steam curing, and demolding quality inspection) through system approval, the component's numerical evolutionary state vector (StateVector) in the production dimension is assigned the value 4.
[0027] A key-value mapping structure is initialized in the memory data structure. The preprocessed 001A2B3C4D5E is used as the key, and the accumulated values of each dimension, represented as a one-dimensional integer array (e.g., Design: 2, Production: 4, Logistics: 1, Installation: 0), are used as the values. These are assembled to construct a standardized vector clock key-value pair: 001A2B3C4D5E:[2,4,1,0]. This key-value pair is converted into a binary byte stream using a serialization protocol and pushed into a FIFO (First-In-First-Out) state cache queue named VectorClock_Cache_Queue, pre-deployed in the memory cache component. The maximum length of this state cache queue is set between 1000 and 5000 entries, and it only uses a FIFO eviction policy. That is, when the queue reaches its maximum length, the earliest written and already persisted or synchronized basic record is evicted first; for basic records that have not yet been persisted, persistence or synchronization is triggered first, and then eviction is performed. In high-concurrency distributed write scenarios, the read and update latency of the multi-dimensional state vector clock base record can be kept within a preset low latency range.
[0028] In an optional embodiment, calculating the vector clock difference between the version of the target component to be written and the current version of each replica along the specific dimension includes: Extract the vector clock record of the version to be written of the target component in the specific dimension, and the vector clock record of the current version of each replica node in the specific dimension; Align the vector clock records of the version to be written with the current version of each replica according to the node identifier, and fill in the specific dimension scalar values corresponding to the missing node identifiers according to the preset initial values. Calculate the difference between the aligned scalar values of a specific dimension, and summarize the difference values corresponding to the same replica node to obtain the clock difference measure of the replica node in the specific dimension. The clock difference measure corresponding to each replica node is stored in a temporary queue.
[0029] When a distributed system receives a write update request for a target component in a specific dimension, the master node's protocol parsing engine deserializes and extracts the complete vector clock record of the version to be written from the network request message. The master node uses an asynchronous remote call protocol to poll in parallel among the N replica nodes responsible for storing the component's data on the distributed hash routing structure. The system typically configures N to be an odd number of replica nodes, not less than 3, and pulls the current vector clock record cached in the memory of these replica nodes. Taking a cluster with three nodes independently identified as NodeA, NodeB, and NodeC as an example, assuming the complete multidimensional state vector record of the version to be written is NodeA:[2,4,1,0], NodeB:[1,2,0,0], and NodeC:[0,1,0,0]. When this write request corresponds to the production dimension, the production dimension scalars 4, 2, and 1 are extracted from the four-dimensional arrays of the three nodes, and arranged in the node identifier order to form V_write_prod=[4,2,1]. This array represents a scalar sequence of different nodes on the same production dimension, and does not represent arrays for the four engineering dimensions of design, production, logistics, and installation.
[0030] After all records have been retrieved, the conflict comparison engine will concurrently traverse the data of the version to be written and the current version of each replica node. The comparison algorithm will align the position indices of nodes with the same node identifier (i.e., the same key), and use absolute value operations to calculate the scalar difference of the corresponding nodes in the specific dimension. For example, if the current production dimension node sequence pulled by replica node NodeA is V_replica_A_prod=[3,2,0], then the scalar difference of each node in the production dimension calculated bit by bit is |4-3|=1, |2-2|=0, |1-0|=1. The sum of the above node differences in this example is 1+0+1=2, which is then combined and output as a numerical clock difference parameter Diff_Score. A temporary queue named Temp_Diff_Queue is created in the main memory space, and key-value pair structures like NodeA_Replica:2 are pushed into the queue as clock difference metrics.
[0031] In an optional embodiment, the step of calculating the correlation conflict entropy value by combining the topological constraint weights includes: The specific dimension clock difference measure corresponding to each replica node in the temporary queue is summarized to obtain the total system difference value; Calculate the average replica conflict metric based on the total system discrepancy value and the number of replica nodes storing the target component replicas; The average replica conflict metric is fused with the topological constraint weight to obtain the correlation conflict entropy value. The associated conflict entropy value is saved as the criterion for subsequently setting the write permission threshold.
[0032] Instantiate a floating-point aggregate variable Total_Diff and initialize it to 0.0. Lock a temporary queue named Temp_Diff_Queue through a polling listener, perform a dequeue operation, and cyclically accumulate the specific dimension clock difference metric values of all replica nodes in it, such as the integer values of 2, 3, 1, etc. calculated in the previous steps, into Total_Diff to obtain the total system difference value for this dimension, assumed to be 6.0. Send a query command to the cluster registry center to obtain the total number M of surviving replica nodes actually carrying the target component data in the current time window. When the total number of surviving replica nodes M is 0, pause the current write permission determination and return a replica unavailability exception; when M is greater than 0, continue to execute the average replica conflict metric calculation. To improve replica fault tolerance and the stability of the master election mechanism, the configuration range of M is set to an odd number such as 3, 5, or 7. Divide the accumulated total system difference value of 6.0 by the total number of replica nodes, for example 3, to calculate the average replica conflict metric representing the degree of global synchronization deviation, for example 6.0 / 3=2.0.
[0033] By calling the graph database or graph structure processing module, a pre-calculated set of topological constraint edge weights is extracted from the edge attribute fields of the component adjacency graph. For example, after a depth-first search traverses the first-order or second-order associated components of the target component, the set of edge weights {4.5, 3.2, 2.1} is obtained. Then, according to the maximum edge weight aggregation rule, 4.5 is selected as the unique topological constraint weight parameter. This aggregation rule ensures that the strongest constraints, such as load-bearing connections and critical path connections, are not diluted by multiple weaker constraints. The weight is set between 0.1 and 5.0, with the specific value directly proportional to the centrality of the target component within the overall building's mechanical support system or the construction critical path network. For example, the topological constraint weight of a core load-bearing column might be assigned the highest level of 4.5 by the system, while a non-load-bearing infill wall component on the periphery might be assigned a value of 0.8. Multiplying the average replica conflict measure of 2.0 by the obtained topological constraint weight of 4.5 yields the comprehensive evaluation value, i.e., the related conflict entropy value E = 2.0 × 4.5 = 9.0. This related conflict entropy value is a comprehensive index representing the product of the average replica conflict measure and the topological constraint weight, used to characterize conflict intensity, and no longer uses the Shannon entropy probability distribution calculation logic. The calculation result 9.0 is converted to a floating-point parameter and persistently saved to the shared context cache area of the current operation, serving as a benchmark for subsequent flexible write permission thresholds. Figure 3 The figure shown is a comparison of conflict metrics, topological weights, and conflict entropy values for different types of prefabricated components.
[0034] S2, based on the correlation conflict entropy value, set a write permission threshold W that is positively correlated with it, calculate the critical weight of each node based on the clock proximity of each replica node in the corresponding dimension of the multi-dimensional state vector clock, and permit the write operation when the cumulative weight of the set of nodes confirming the write request is not less than the write permission threshold W.
[0035] The correlation conflict entropy value calculated in the preceding steps is obtained. This value is then converted into a conflict penalty increment using a basic weight normalization coefficient. This conflict penalty increment is combined with a basic threshold that is strictly greater than 50% of the total system weight to calculate the dynamic write permission threshold W. For clock recentity calculation in the corresponding dimension of the multi-dimensional state vector clock, the clock count value of each replica node in that specific dimension is extracted. The maximum count value among all replica nodes is determined. When the maximum count value is greater than 0, the count value of each replica node is divided by the maximum count value to obtain a normalized clock recentity. This clock recentity is then exponentially normalized to obtain the recentity percentage of each node. When the maximum count value is equal to 0, the same initial value is used for exponential normalization to obtain the recentity percentage of each node, or it is directly normalized according to a preset initial weight. The recentity percentage is then mapped to a unified integer weight scale to form a critical weight with the same dimension as the write permission threshold W. The critical weights are calculated solely based on the clock recentity of the corresponding engineering dimension, and are no longer evaluated based on CPU computing power, network card bandwidth margin, or historical response latency.
[0036] When the coordinating node receives write permission pre-acknowledgment responses from each replica node, it accumulates the critical weights of the nodes that have returned pre-acknowledgment responses in real time to obtain a weight accumulation value. It then determines whether this weight accumulation value is greater than or equal to the write permission threshold W. If the condition is met, the coordinating node sends a write commit command to the replica nodes in the acknowledgment set, causing the replica nodes to perform persistent writing of the target component data and the updated multidimensional state vector clock, and return a write success status code to the client. The updated multidimensional state vector clock is obtained by merging the current multidimensional state vector clocks of the version to be written and the replica nodes in the acknowledgment set according to node identifier alignment. For the same node identifier, the maximum value of the count values for each engineering dimension is taken, and the count value of the initiating write node in the specific dimension is updated according to the cumulative value of the approval log corresponding to this write. The write permission threshold W is always set to a value strictly greater than 50% of the total system weight to avoid two disjoint node sets simultaneously satisfying the write permission condition.
[0037] In an optional embodiment, setting a write permission threshold W that is positively correlated with the correlation conflict entropy value includes: Based on the correlation conflict entropy value and the preset weight mapping parameters, a conflict penalty increment is generated that is on the same weight scale as the node critical weight; Obtain the critical weights of each replica node storing the target component replica, and summarize the critical weights to obtain the total system weight; A basic threshold that is strictly greater than half of the total system weight is generated based on the total system weight. The candidate write permission threshold is obtained by superimposing the base threshold and the conflict penalty increment. The candidate write permission threshold is constrained by an upper limit based on the total weight of the system to obtain the current write permission threshold W of the target component.
[0038] The distributed consensus module reads the floating-point associative conflict entropy value variable E from the context buffer; for example, if the value is 9.0, it multiplies this value by a pre-defined base weight normalization coefficient α in the system's global configuration table. This coefficient α is configured within the range of 0.5 to 2.0 to smoothly scale the conflict entropy value to a scale space on the same order of magnitude as the node's critical weight parameters. Assuming the system assigns an α value of 1.5, the multiplication calculates the conflict penalty increment. =9.0 × 1.5 = 13.5. The coordinating node broadcasts metadata probe commands in parallel to the entire replication group containing the target component replica, collecting the vector clock count values of each participating node in the target project dimension in real time. For example, first obtain the maximum clock count value of each node in the target project dimension. ;when When the value is greater than 0, the clock recentity is calculated for each node. Where i is the node index, i=1,2,...,M, and M is the total number of currently surviving replica nodes. This represents the clock count value of the i-th node in the target project dimension. Let be the clock recentity of the i-th node; when When the value is 0, the clock recentity of each node is uniformly set to the same initial value, and the recentity ratio is obtained through exponential normalization. Alternatively, the recentity ratio can be obtained directly by normalizing according to the preset initial weights. Then Multiplying the calculated results of each node by the preset weight scale S of the replication group, the initial criticality weight of each node is obtained by rounding down. The difference between the sum of the initial criticality weights and the weight scale S is used as the residual difference and compensated to the node with the highest proximity. When there are multiple nodes with the same proximity, the compensation node is determined according to the lexicographical order of the node identifiers or the preset node priority. The resulting criticality weights can be expressed as integer values such as 30, 25, 40, 20, and 35, but these integer values come from the clock proximity mapping, not from node hardware resources or network resources. Assuming that the replication group consists of 5 healthy nodes, and their calculated criticality weights are 30, 25, 40, 20, and 35, the total system weight is obtained by summing these values. It is 150.
[0039] To ensure the fundamental quorum mechanism of the consensus protocol, the total weight of the system is... The baseline threshold is 50% of 150, resulting in 75. A minimum integer weight confirmation unit of 1 is added to this baseline, resulting in a strict majority baseline threshold of 76. Addition is performed to add the baseline threshold 76 to the converted conflict penalty increment of 13.5, yielding a floating-point sum of 89.5. To comply with the integer-based permission decision logic, 89.5 is rounded up, generating an unsigned integer candidate threshold of 90. The boundary constraint comparison logic compares the generated candidate integer value 90 with the system's total weight of 150. Since 90 does not exceed the upper limit of the system's total weight, the current write permission threshold W for this component is updated to 90. Conversely, in a high-concurrency environment causing numerous conflicts, if the penalty increment increases to a rounded candidate value such as 165, the boundary constraint comparison logic will trigger a maximum limit truncation mechanism upon detecting an out-of-bounds situation, truncating the target component's write permission threshold W to the system's total weight of 150. Since the current threshold of 90 is strictly greater than half of the total system weight of 150, any two write confirmation sets that meet the threshold condition will inevitably have a weight intersection, thereby reducing the risk of split-brain writes and dirty data generation.
[0040] S3 sets components with constraints as an assembly set, generates dimension-specific Merkle root hashes in four dimensions, and combines the four dimension Merkle root hashes into a composite digest signature. Nodes achieve targeted incremental synchronization of data in specific dimensions by first comparing the composite digest signature and then comparing the Merkle root hashes of each dimension as needed.
[0041] Based on the set of nodes with interdependent edges in the topologically constrained adjacency graph, the directed topologically constrained adjacency graph is treated as an undirected graph during the assembly set partitioning stage, and a weakly connected component algorithm is used to extract subgraphs, which are then designated as the assembly set. For all component data within this assembly set, data fields for four dimensions—design, production, logistics, and installation—are extracted. These data are then deterministically sorted according to the component's unique identifier, log generation timestamp, and log sequence number. The sorted dimensional data is then divided into multiple leaf node data blocks. Each leaf node data block is hashed, and four independent Merkle trees are constructed through a cascading hashing process, yielding four Merkle root hashes for each dimension. These four Merkle root hashes are concatenated into a root hash combination string in a fixed order of design, production, logistics, and installation. A secure hashing algorithm, consistent with the aforementioned Merkle root hash generation process, is then used to hash the concatenated long string, generating a composite digest signature. This composite digest signature is a data consistency verification digest generated based on the hash operation. The input for the composite digest signature must maintain deterministic consistency across all nodes, without using locally generated random salt values. If system security policies require the addition of salt values, a fixed salt value determined by the assembly set UUID, system version number, or global configuration table is used. During background anti-entropy synchronization between nodes, a node-to-node anti-entropy broadcast protocol is used to periodically broadcast the composite digest signature to neighboring nodes. The receiving node compares the received composite digest signature with its local composite digest signature; if they do not match, it requests the sender to transmit the Merkle root hashes for all four dimensions. A bitwise comparison algorithm is executed sequentially to identify the specific dimension where data discrepancies occur. After locking onto the specific dimension, a breadth-first search algorithm is used to compare the hash values of internal nodes layer by layer down the Merkle tree along that dimension to locate the changed target component data block. The differential coding synchronization algorithm is then invoked to request and transmit only missing or changed data blocks, achieving targeted incremental synchronization.
[0042] In an optional embodiment, the step of setting the components with constraints as an assembly set, generating dimension-specific Merkle root hashes in four dimensions, and combining the four Merkle root hashes into a composite digest signature includes: Extract the dimensional status data and corresponding log data streams of the component assembly set in the four dimensions of design, production, logistics and installation respectively; Based on the dimensional state data and corresponding log data streams of each dimension, four independent Merkle root hashes are generated respectively; The Merkle root hashes of the four independent dimensions are combined in a preset dimensional order, and a second hash operation is performed on the combination result to generate a composite digest signature of the component assembly set. The composite digest signature is stored in the target verification pool for data synchronization and comparison between nodes.
[0043] The distributed log collection daemon deployed in the background utilizes a sliding time window polling mechanism to extract four exclusive dimensions of log data streams—design, production, logistics, and installation—from the multi-dimensional transaction ledger at the underlying level of the component assembly set. These log streams contain key details such as geometric parameter corrections and approval node transitions. To prevent memory overflow caused by a single parsing operation and to ensure hash calculation performance, the payload size of each extracted and fed data packet is sliced and controlled within the range of 2MB to 10MB. Subsequently, four completely isolated asynchronous hash calculation threads are instantiated, using the aforementioned four separated log data packets as raw byte input streams, and concurrently feeding them into the hash calculation engine. Within each individual dimension's computation pool, the engine deterministically sorts all underlying discrete log entries according to the combination of component unique identifier, log generation timestamp, and log sequence number. Then, it performs basic hashing on the sorted log entries to obtain the underlying leaf node layer. The engine then performs bottom-up computation using a Merkle tree binary tree with pairwise concatenated hashing of adjacent nodes, outputting four 256-bit hash values at the tree vertices, or the independent dimension's Merkle root hash value represented by 64 hexadecimal characters. These values are then assigned and marked in memory. , , and .
[0044] After the independent dimensionality reduction and compression of the four dimensions are completed, the orderly sequential process begins. The underlying principles follow the entire lifecycle of prefabricated building business flow sequence: design precedes production, production precedes logistics, and logistics ultimately leads to installation. This is achieved by calling string concatenation components, according to… The sequence is processed by string concatenation, combining four root hashes of 64 hexadecimal characters each, into a single root hash string of 256 characters. This concatenated string is then directly passed to the secondary operation queue. In deployment scenarios requiring salt values, only deterministic Salts derived from the assembly set UUID and the system global version number are allowed; randomly generated Salts on the node are not permitted. The final-state secondary hash mapping is performed using the same hash calculation engine. In this step, the multidimensional sequence fingerprint generates a unique new 256-bit fixed-length hash value, or a fixed-length hash string represented by 64 hexadecimal characters, which is recognized as the composite digest signature of the component assembly set at the current snapshot. This signature, along with the composite verification packet containing the original four independent root hashes, is converted using a serialization protocol and stored in the target verification pool within the distributed caching architecture, using the assembly set UUID as the key. During subsequent cross-node full or incremental data verification, the comparison end only needs to verify whether the composite signature matches through a constant-level digest comparison operation to complete the initial rejection, avoiding traversal comparison at the level of massive structured messages. Since the same assembly set data uses the same input to generate composite digest signatures on different nodes, false conflict alarms will not be generated due to differences in random salts.
[0045] In a second embodiment, the present invention also proposes a construction system for intelligent prefabricated buildings, comprising the following modules: The module is used to assign a unique identifier to prefabricated building components as the key, construct a component data object containing component attributes, a multidimensional state vector clock, and a topological constraint adjacency graph as the value, and construct the multidimensional state vector clock, which consists of node identifiers and evolutionary state vectors, to track the state transitions of components in four dimensions: design, production, logistics, and installation. When a node initiates a write request for a specific dimension of the target component, the concurrent version is identified based on the multidimensional state vector clock, the topological constraint weights are obtained by traversing the associated components using the adjacency graph, the vector clock difference between the target component's version to be written and the current version of each replica in the specific dimension is calculated, and the correlation conflict entropy value is generated by combining the topological constraint weights. The calculation module is used to set a write permission threshold W that is positively correlated with the correlation conflict entropy value, calculate the critical weight of each node based on the clock proximity of each replica node in the corresponding dimension of the multidimensional state vector clock, and permit the write operation when the cumulative weight of the set of nodes confirming the write request is not less than the write permission threshold W. The generation module is used to set components with constraints as an assembly set, generate dimension-specific Merkle root hashes in four dimensions, and combine the Merkle root hashes of the four dimensions into a composite digest signature. Nodes achieve targeted incremental synchronization of data in specific dimensions by first comparing the composite digest signature and then comparing the Merkle root hashes of each dimension as needed.
[0046] The above description represents the preferred embodiments of the present invention. It should be noted that, for those skilled in the art, various improvements and modifications can be made without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.
Claims
1. A method for constructing an intelligent prefabricated building, characterized in that, Includes the following steps: A unique identifier is assigned as the key to each prefabricated building component. A component data object containing component attributes, a multidimensional state vector clock, and a topological constraint adjacency graph is constructed as the value. The multidimensional state vector clock is constructed, which consists of node identifiers and evolutionary state vectors. It tracks the state transitions of the component in four dimensions: design, production, logistics, and installation. When a node initiates a write request for a specific dimension to the target component, the concurrent version is identified based on the multidimensional state vector clock. The topological constraint weights are obtained by traversing the associated components using the adjacency graph. The vector clock difference between the version to be written of the target component and the current version of each replica in the specific dimension is calculated. The correlation conflict entropy value is generated by combining the topological constraint weights. Based on the correlation conflict entropy value, a write permission threshold W is set that is positively correlated with it. Based on the clock proximity of each replica node in the corresponding dimension of the multidimensional state vector clock, the critical weight of the node is calculated. When the cumulative weight of the set of nodes that confirm the write request is not less than the write permission threshold W, the write operation is permitted. Components with constraints are set as an assembly set, and dimension-specific Merkle root hashes are generated in four dimensions. The Merkle root hashes of the four dimensions are combined into a composite digest signature. Nodes achieve targeted incremental synchronization of data in specific dimensions by first comparing the composite digest signature and then comparing the Merkle root hashes of each dimension as needed.
2. The method according to claim 1, characterized in that, The construction of the multidimensional state vector clock, which consists of node identifiers and evolutionary state vectors, includes: Obtain the node-specific identifier of the distributed nodes; Collect the cumulative values of the state transition of prefabricated building components in various engineering dimensions such as design, production, logistics, and installation, and generate a numerical component evolution state vector; Using the node's independent identifier as the key and the numerical component evolution state vector as the value, construct a vector clock key-value pair; The vector clock key-value pairs are stored in the state cache queue as the basic record of the multidimensional state vector clock.
3. The method according to claim 2, characterized in that, The calculation of the vector clock difference between the version of the target component to be written and the current version of each replica along the specific dimension includes: Extract the vector clock record of the version to be written of the target component in the specific dimension, and the vector clock record of the current version of each replica node in the specific dimension; Align the vector clock records of the version to be written with the current version of each replica according to the node identifier, and fill in the specific dimension scalar values corresponding to the missing node identifiers according to the preset initial values. Calculate the difference between the aligned scalar values of a specific dimension, and summarize the difference values corresponding to the same replica node to obtain the clock difference measure of the replica node in the specific dimension. The clock difference measure corresponding to each replica node is stored in a temporary queue.
4. The method according to claim 1, characterized in that, The step of calculating and generating the correlation conflict entropy value by combining the topological constraint weights includes: The specific dimension clock difference measure corresponding to each replica node in the temporary queue is summarized to obtain the total system difference value; Calculate the average replica conflict metric based on the total system discrepancy value and the number of replica nodes storing the target component replicas; The average replica conflict metric is fused with the topological constraint weight to obtain the correlation conflict entropy value. The associated conflict entropy value is saved as the criterion for subsequently setting the write permission threshold.
5. The method according to claim 4, characterized in that, The step of setting a write permission threshold W that is positively correlated with the correlation conflict entropy value includes: Based on the correlation conflict entropy value and the preset weight mapping parameters, a conflict penalty increment is generated that is on the same weight scale as the node critical weight; Obtain the critical weights of each replica node storing the target component replica, and summarize the critical weights to obtain the total system weight; A basic threshold that is strictly greater than half of the total system weight is generated based on the total system weight. The candidate write permission threshold is obtained by superimposing the base threshold and the conflict penalty increment. The candidate write permission threshold is constrained by an upper limit based on the total weight of the system to obtain the current write permission threshold W of the target component.
6. The method according to claim 1, characterized in that, The process involves defining components with constraints as an assembly set, generating dimension-specific Merkle root hashes in four dimensions, and combining the four Merkle root hashes into a composite digest signature, including: Extract the dimensional status data and corresponding log data streams of the component assembly set in the four dimensions of design, production, logistics and installation respectively; Based on the dimensional state data and corresponding log data streams of each dimension, four independent Merkle root hashes are generated respectively; The Merkle root hashes of the four independent dimensions are combined in a preset dimensional order, and a second hash operation is performed on the combination result to generate a composite digest signature of the component assembly set. The composite digest signature is stored in the target verification pool for data synchronization and comparison between nodes.
7. A construction system for intelligent prefabricated buildings, characterized in that, Includes the following modules: The module is used to assign a unique identifier to prefabricated building components as the key, construct a component data object containing component attributes, a multidimensional state vector clock, and a topological constraint adjacency graph as the value, and construct the multidimensional state vector clock, which consists of node identifiers and evolutionary state vectors, to track the state transitions of components in four dimensions: design, production, logistics, and installation. When a node initiates a write request for a specific dimension of the target component, the concurrent version is identified based on the multidimensional state vector clock, the topological constraint weights are obtained by traversing the associated components using the adjacency graph, the vector clock difference between the target component's version to be written and the current version of each replica in the specific dimension is calculated, and the correlation conflict entropy value is generated by combining the topological constraint weights. The calculation module is used to set a write permission threshold W that is positively correlated with the correlation conflict entropy value, calculate the critical weight of each node based on the clock proximity of each replica node in the corresponding dimension of the multidimensional state vector clock, and permit the write operation when the cumulative weight of the set of nodes confirming the write request is not less than the write permission threshold W. The generation module is used to set components with constraints as an assembly set, generate dimension-specific Merkle root hashes in four dimensions, and combine the Merkle root hashes of the four dimensions into a composite digest signature. Nodes achieve targeted incremental synchronization of data in specific dimensions by first comparing the composite digest signature and then comparing the Merkle root hashes of each dimension as needed.
8. The system according to claim 7, characterized in that, The construction of the multidimensional state vector clock, which consists of node identifiers and evolutionary state vectors, includes: Obtain the node-specific identifier of the distributed nodes; Collect the cumulative values of the state transition of prefabricated building components in various engineering dimensions such as design, production, logistics, and installation, and generate a numerical component evolution state vector; Using the node's independent identifier as the key and the numerical component evolution state vector as the value, construct a vector clock key-value pair; The vector clock key-value pairs are stored in the state cache queue as the basic record of the multidimensional state vector clock.
9. The system according to claim 7, characterized in that, The calculation of the vector clock difference between the version of the target component to be written and the current version of each replica along the specific dimension includes: Extract the vector clock record of the version to be written of the target component in the specific dimension, and the vector clock record of the current version of each replica node in the specific dimension; Align the vector clock records of the version to be written with the current version of each replica according to the node identifier, and fill in the specific dimension scalar values corresponding to the missing node identifiers according to the preset initial values. Calculate the difference between the aligned scalar values of a specific dimension, and summarize the difference values corresponding to the same replica node to obtain the clock difference measure of the replica node in the specific dimension. The clock difference measure corresponding to each replica node is stored in a temporary queue.
10. The system according to claim 7, characterized in that, The step of calculating and generating the correlation conflict entropy value by combining the topological constraint weights includes: The specific dimension clock difference measure corresponding to each replica node in the temporary queue is summarized to obtain the total system difference value; Calculate the average replica conflict metric based on the total system discrepancy value and the number of replica nodes storing the target component replicas; The average replica conflict metric is fused with the topological constraint weight to obtain the correlation conflict entropy value. The associated conflict entropy value is saved as the criterion for subsequently setting the write permission threshold.
