Construction site material RFID tracking and BIM collaborative management system

Abstract

The application discloses a construction site material RFID tracking and BIM collaborative management system, and particularly relates to the field of building engineering digital management, and is used for solving the problems of label and component correspondence invalidation caused by replacement and splitting operation, evidence chain rupture, progress annotation bifurcation and acceptance voucher deviation, and is used for realizing full-link traceability and collaborative consistency of materials from entry to installation through the following steps: identity mapping module is used for correcting events and establishing one-to-one correspondence between label keys and model keys; evolution sealing module is used for detecting changes, generating new instances and constructing parent-child pedigree redirection events; cause-effect chain module is used for organizing read-write events into monotonic sequences and promoting states; mutual evidence adjudication module is used for fusing identity chain and space path evidence to calculate decision coefficients and trigger backtracking correction; and iterative archiving module is used for summarizing checking results, optimizing rules and solidifying snapshots.

Description

Technical Field

[0001] This invention relates to the field of digital management of construction projects, and more specifically, to a construction site material RFID tracking and BIM collaborative management system. Background Technology

[0002] At the construction site, RFID tags are used to carry identity information for the entry, stacking, allocation, hoisting and installation of components, and building information models are used to carry component instances and process status. After the on-site read and write events are transmitted back, they are colored, located and issued in the 3D view, with the aim of achieving integrated collaboration and traceability management from the supply end to the installation end.

[0003] However, after operations such as replacement, splitting, or repackaging are introduced, the original one-to-one correspondence between label codes and component instances no longer holds. Read and write events are easily linked to expired or incorrect objects, causing progress markings and inventory locations to diverge between the visualization and ledgers. The reported quantities and acceptance criteria cannot be consistent with the actual installed objects, and quality inspection records are difficult to align with actual components. This creates a technical problem of irreversible identity evolution and broken evidence chains, directly impacting the goals and credibility of material tracking and collaborative management of building information models.

[0004] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a construction site material RFID tracking and BIM collaborative management system. This system utilizes an identity mapping module to unify time-stamped correction of tag events and model instance information, establishing a one-to-one correspondence between tag keys and model keys. An evolution and archiving module detects replacement or splitting operations, generates new instance identifiers, and constructs a parent-child relationship table to redirect events and form a complete genealogy. A causal chaining module uses the new instance identifier as an entry point to organize read and write events into a monotonic causal sequence and advances state verification. A mutual verification and adjudication module integrates identity chain evidence and spatial path evidence to calculate decision coefficients, triggering hierarchical backtracking correction and writing back to the identity mapping table. An iterative archiving module summarizes the verification results, iteratively updates the identity evolution rules, and solidifies snapshots to output verification credentials, thereby solving the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] Construction site material RFID tracking and BIM collaborative management system, including:

[0008] Identity mapping module: Collects tag events and model instance information under a unified time scale, generates an identity base table and establishes a correspondence between tag keys and model keys, and marks the instance status and its construction unit;

[0009] Evolution and archiving module: When a replacement or split operation occurs, a new instance identifier is generated according to the identity evolution rules and a parent-child relationship table is established. The original instance identifier is transferred to the history area and event writing is stopped.

[0010] Causal Chaining Module: Receives read and write events with the new instance identifier as the unique entry point and writes them into the evidence chain list. The evidence chain list organizes parent-child relationships and state changes in chronological order to form a causal sequence.

[0011] Mutual verification adjudication module: At the consistency verification point, the corresponding backtracking method is selected based on the comprehensive analysis results of identity chain evidence and spatial path evidence, the scope of correction is defined, and a correction record is generated and the identity mapping is written back.

[0012] Iterative archiving module: In the continuous running window, the identity evolution rules are iteratively updated based on the consistency verification results and correction records, and the verified mapping table and acceptance certificate are output and archived for the current batch.

[0013] Furthermore, the identity mapping module uses a unified time stamp to calculate the time offset for each source based on a reference clock and corrects the event timestamp. It uses the tag key, read / write point identifier, read / write pose, event type, and event coordinates in the tag event as fields, and combines them with the model key, instance status, construction unit, instance geometric anchor point, and instance coordinates in the model instance information to generate an identity base table.

[0014] Furthermore, the identity mapping module establishes a correspondence by performing precise matching of the tag key in the historical mapping table. If no match is found, candidate model keys are filtered based on the principle of minimizing the reachable distance from the instance's geometric anchor point to the event coordinates. Then, a unique model key is obtained by consistent trimming based on the construction unit boundary and the read / write point coverage area. This unique model key is written into the identity base table and the instance status and its associated construction unit are marked.

[0015] Furthermore, the evolution and sealing module detects replacement or splitting operations, generates new instance identifiers based on identity evolution rules, and creates new records in the identity base table. It also establishes a parent-child relationship table to record the subordinate and replacement relationships between the new instance identifier and the original instance identifier. The parent-child relationship table records the parent instance identifier, child instance identifier, evolution type, trigger event identifier, evolution time, and evolution reason.

[0016] Furthermore, the evolution and sealing module moves the original instance identifier into the history area and sets the write status to frozen. The freezing action is executed on the receiving end, redirecting the subsequent event write request with the original instance identifier as the target to the new instance identifier. The redirection record is recorded in the parent-child relationship table to form a complete genealogy. If it is split, multiple child instance identifiers are registered in the parent-child relationship table according to the component split list. The parent-child chain maintains the order without breakpoints under the same time scale.

[0017] Furthermore, the causal chaining module receives read and write events with the new instance identifier as the sole entry point, sorts them according to the event timestamp, and writes them into the evidence chain list. Based on the parent-child relationship table, it inserts evolution nodes into the evidence chain list to connect evolution edges. Subsequently, it generates a causal sequence by jointly sorting the time order and the subordinate order. The causal sequence organizes the sequence nodes according to the instance dimension, covering the actions of arrival, warehousing, warehousing, hoisting, positioning, acceptance, and evolution. The sequence edges indicate the true sequence relationship and subordinate transformation.

[0018] Furthermore, the causal chaining module adopts an adjacent deduplication strategy for events repeatedly triggered by the same terminal within a short period of time. The deduplication rule is based on the triple of event type, location index and terminal identifier. The deduplicated sequence remains monotonic and does not backtrack. After the causal sequence is generated, the state is advanced using an instance state machine. The state advancement indicates the determined previous state, triggering event type and subsequent state. If the advancement fails, the abnormal node is marked in the evidence chain list.

[0019] Furthermore, the mutual evidence adjudication module calculates the parent-child genealogy completeness at the consistency check point, performs genealogy expansion on the parent-child relationship table to construct an evolution path set from the initial instance to the current instance, and performs one-to-one mapping between the path set and the evidence chain. Unrecorded evolution segments are marked as gap segments, and the total number of continuously recognizable segments and the distribution of gap segments form a hierarchy.

[0020] Furthermore, the mutual verification adjudication module calculates the consistency difference of reachable path order. It extracts doors, stairs, freight elevators, unloading platforms, and temporary passages from model instance information to construct reachable connectivity relationships covering construction units, generating a construction path sequence from the previous location point to the current location point. It projects the event location sequence in the evidence chain onto the connectivity relationship, counts the number of reverse traversals and the number of crossings of closed boundaries, and locates the occurrence segment. The decision coefficient is obtained by combining the two with the reachability falsification coefficient.

[0021] Furthermore, the iterative archiving module summarizes the consistency verification results and correction records within the continuous running window, performs iterative updates on the identity evolution rules, including replacement and splitting trigger boundaries, fault tolerance boundaries for genealogical gaps, boundary adjustments for read / write point coverage areas, and temporary channel changes in connectivity relationships. Updates are written to the rule version library in a versioned manner and the effective version is recorded in the identity mapping table. The current batch is archived, including snapshots of the identity base table, parent-child relationship table, evidence chain list, identity mapping table, and rule version number.

[0022] The technical effects and advantages of the construction site material RFID tracking and BIM collaborative management system of this invention are as follows:

[0023] This invention constructs a one-to-one mapping between tag keys and model keys under a unified time scale, incorporating replacement and splitting into a traceable evidence chain based on identity evolution and parent-child lineage. It uses a causal sequence to connect the status progression of arrival, warehousing, hoisting, positioning, and acceptance. At the consistency check point, it combines identity chain evidence and spatial path evidence to generate a decision coefficient, thereby triggering bounded backtracking correction and identity mapping write-back. This ensures identity stability, mapping convergence, and consistency between views, ledgers, and vouchers. The entire process is constrained by versioning rules, avoiding misalignment and causal reversal caused by the latest event overwriting, eliminating spatial deviations caused by proximity-based connections, and ensuring that replaced and split components remain continuously within a complete traceability chain. This forms a reliable evidence system for settlement, quality assurance, and auditing, strengthening the certainty and verifiability of collaborative management. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the RFID tracking and BIM collaborative management system for construction site materials according to the present invention. Detailed Implementation

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

[0026] Example 1: Figure 1 The present invention provides a construction site material RFID tracking and BIM collaborative management system, comprising:

[0027] Identity mapping module: Collects tag events and model instance information under a unified time scale, generates an identity base table, establishes a correspondence between tag keys and model keys, and marks the instance status and its construction unit.

[0028] Evolution and archiving module: When a replacement or split operation occurs, a new instance identifier is generated according to the identity evolution rules and a parent-child relationship table is established. The original instance identifier is transferred to the history area and event writing is stopped.

[0029] Causal Chaining Module: The module receives read and write events and writes them to the evidence chain list, which is organized in chronological order to form a causal sequence based on parent-child relationships and state changes.

[0030] The mutual verification adjudication module selects the corresponding backtracking method based on the comprehensive analysis of identity chain evidence and spatial path evidence at the consistency verification point, defines the scope of correction, generates correction records, and writes back the identity mapping.

[0031] Iterative archiving module: In the continuous running window, the identity evolution rules are iteratively updated based on the consistency verification results and correction records, and the verified mapping table and acceptance certificate are output and archived for the current batch.

[0032] Tag events and model instance information serve as core data sources, directly supporting end-to-end traceability from component arrival to installation. However, since replacement or splitting operations may disrupt the initial correspondence between tag keys and model keys, relying solely on event feedback is insufficient to maintain the synchronization consistency between the visual view and the ledger. This requires the identity mapping module to first construct a reliable identity base table, using unified timestamp correction of event timestamps and establishing a one-to-one correspondence through precise matching and spatial consistency pruning. This provides a stable mapping starting point for subsequent evolution, sealing, and causal chaining modules, avoiding progress marking forks and acceptance basis deviations caused by reading and writing events being attached to expired objects, and ensuring the traceability of material identities from the supply end to the installation end is established.

[0033] The specific processing logic of the identity mapping module:

[0034] 1.1: Collect label events and model instance information and apply unified time-scale correction.

[0035] The data acquisition process, for each read / write event, retrieves the tag key, read / write point identifier, read / write pose, event type, and event coordinates from the RFID reader. Simultaneously, it extracts the corresponding model key, instance status, construction unit, instance geometric anchor point, and instance coordinates from the Building Information Model (BIM). Unified timescale calibration uses a reference clock as a benchmark, calculating the time offset for both the tag event timestamp and the model instance information timestamp. The time offset is defined as the difference between the event recording time and the reference clock time. A synchronization pulse signal is pre-set between the reader and the model server, triggering a full-network calibration once daily at midnight. The offset calculation uses a linear interpolation method based on the pulse signal propagation delay; that is, the offset equals the cumulative delay within the pulse interval divided by the signal frequency.

[0036] At the moment of data acquisition, the reader reports the original timestamp along with the local clock offset, while the model server includes its geometric anchor point update time; the correction formula is the correction timestamp. ,in Represents the original timestamp. The time offset is represented (calculated from pulse synchronization); after correction, all collected information is uniformly labeled with a unified timestamp to form a dataset to be processed.

[0037] The dataset to be processed contains corrected label events and model instance information, providing basic data for time synchronization for the subsequent generation of the identity base table. This avoids event sequence disorder caused by clock drift and ensures that the coordinates of the entry and stacking events are aligned with the geometric anchor points of the model instances under the same time scale in the dynamic allocation scenario at the construction site, thereby maintaining the visualization accuracy of material location.

[0038] 1.2: Generate an identity base table based on the dataset to be processed.

[0039] Based on the dataset to be processed, initialize the identity base table structure. This table contains a unique primary key, tag key, model key, instance status, construction unit, timestamp, spatial index, and matching basis fields. The spatial index uses a quadtree to encode the coordinate projection of the tag key and model key to support subsequent fast queries.

[0040] Traverse the dataset to be processed, sort the tag events and model instance information in ascending order according to the unified timestamp, and insert empty records into the identity base table one by one. The unique primary key is generated by concatenating the hash of the unified timestamp and the tag key (the hash function is SHA-256 to ensure uniqueness). During the initial insertion, the model key, instance status, construction unit, spatial index and matching basis fields are temporarily set to empty values. Only the known fields such as tag key, timestamp and event type are filled to form the skeleton record of the identity base table.

[0041] The identity base table skeleton records the label event information of the dataset to be processed in chronological order. It reserves model key padding positions for establishing correspondence. During normal entry before the replacement operation, this skeleton ensures that the reading and writing events do not lose temporal continuity, lays an ordered data foundation for subsequent double key alignment, and avoids isolated event coordinates during stacking and allocation.

[0042] 1.3: Perform exact matching using the tag key in the historical mapping table; if no match is found, filter candidate model keys.

[0043] For each tag key in the identity base table skeleton record, first query the historical mapping table (this table stores the stable tag keys and model keys verified in previous batches). If an exact match exists, directly copy the model key to the model key field of the identity base table skeleton record and set the matching basis to "historical exact match". If no match is found, filter candidate model keys according to the principle of minimizing the reachable distance from the instance geometric anchor point to the event coordinates.

[0044] Historical mapping table queries use the tag key as the primary key index, with a hit threshold set to strings that are completely equal; in case of a miss, the reachability distance is calculated using the following formula: ,in The coordinates of the instance geometric anchor point (the center point of the predefined component in the BIM model) represent the model instance. The coordinates of the tag event (obtained by the reader / writer positioning) are used; the minimum distance filter selects the five closest unmapped model instances within the construction unit as the candidate model key set.

[0045] The identity base table skeleton records some model keys that have been filled with candidate or historical matching values. In the transfer when the split operation has not occurred, this screening ensures that the spatial relationship between the event coordinates and the geometric anchor points is initially established, providing a candidate set for consistent pruning and avoiding inventory location forks caused by nearby incorrect attachments.

[0046] 1.4: Unique model keys are obtained by consistent trimming of the construction unit boundary and the read / write point coverage area.

[0047] For the selected set of candidate model keys, consistency trimming is performed using the construction unit boundary (the fence polygon defined in BIM) and the read / write point coverage area (the signal radius circle corresponding to the read / write point identifier, such as 3 meters by default): only candidate model keys that simultaneously satisfy the condition of containing instance geometric anchor points within the boundary and overlapping the event coordinates are retained. If the result is unique, it is used as the final model key; otherwise, it is marked as pending verification.

[0048] Boundary checking uses a point-on-polygon algorithm to determine whether the instance's geometric anchor point is inside the polygon; the formula for calculating coverage overlap is... ,in This represents the area of ​​the intersection between the event coordinate circle and the read / write point coverage area (calculated through geometric intersection). Represents the area covered by the read / write point (fixed value) , (with radius); after clipping, if a unique model key is matched, the model key field of the skeleton record in the identity base table is filled, and the matching basis is updated to "spatial consistency clipping".

[0049] The model key field of the identity base table skeleton record is uniquely filled. During installation, this trimming eliminates cross-unit interference, ensures a stable correspondence between the label key and the model key, provides an accurate anchor point for the status of the labeled instance and its corresponding construction unit, and avoids deviations between the acceptance criteria and the actual installed object.

[0050] 1.5: Write the identity base table and mark the instance status and the construction unit to which it belongs.

[0051] Based on the obtained unique model key, update the identity base table skeleton record: copy the instance status and the construction unit to which it belongs from the model instance information to the corresponding field, and calculate the spatial index (instance coordinate quadtree encoding based on the unique model key) and the matching basis (splitting historical matches or spatial clipping descriptions).

[0052] Status labels are directly assigned to instance statuses (e.g., "Inbound" or "Lifting"), and the corresponding construction unit inherits this information from the model instance; the spatial index coding formula is... ,in The quadtree quadrant code (dimensionless integer, 0-3) representing the coordinate components is hierarchically encoded based on the instance coordinates normalized to the [0,1] interval to ensure index uniqueness; write operations are executed atomically, and the entire record is rolled back if any field update fails.

[0053] The identity base table fully records the one-to-one correspondence between the tag key and the model key, and retains the matching basis. In the traceability of the entire life cycle of materials, this labeling ensures that the status and unit information are synchronized, providing a traceable initial identity for the construction of the parent-child relationship table of the evolution and sealing module, and avoiding the impact of the broken evidence chain on the credibility of collaborative management.

[0054] The identity mapping module constructs an identity base table containing fields such as unique primary keys, tag keys, and model keys through the orderly connection of unified time stamp correction, skeleton generation, precise matching, and spatial pruning. Under the potential interference of replacement and splitting at the construction site, it ensures that the correspondence between tag events and model instances is stable and the state units are marked, providing a consistent mapping basis for the identity evolution and causal sequence generation of subsequent modules. This eliminates the risk of fork between the visualization end and the ledger and achieves the certainty of material tracking.

[0055] The identity mapping module collects tag events and model instance information under a unified time scale to generate an identity base table, and establishes a one-to-one correspondence between tag keys and model keys through historical precise matching and spatial consistency pruning, while also marking the instance status and the construction unit to which it belongs.

[0056] Establishing a stable one-to-one correspondence between tag keys and model keys in the identity base table provides a reliable mapping foundation for the normal tracking of materials from entry to installation at the construction site. However, when replacement or splitting operations are involved, the continuous event writing of the original instance identifier will destroy this correspondence stability, leading to a break in the evidence chain and deviations in acceptance certificates. This forces the evolution and sealing module to intervene to detect such operations, generate new instance identifiers and build a parent-child relationship table, while freezing the old identifiers and redirecting subsequent events. In this way, the integrity of the genealogy is maintained under the constraints of the identity evolution rules, ensuring that materials can still be seamlessly traced back to the parent source even after splitting into multiple child instances, avoiding misassignment of identities and bifurcation of progress markings during the allocation and installation process.

[0057] The specific processing logic of the evolution and sealing module:

[0058] 2.1: Detect replacement or split operations.

[0059] For the latest record in the identity base table, continuously monitor the read / write event sequence for predefined replacement or split trigger signals. These signals include tag key changes accompanied by consecutive reads and writes of the same model key, or events marked as "split" with an attached split list. The detection logic prioritizes checking the event type field. If it's a replacement, it verifies whether the binding between the tag key and the original model key has deviated from spatial consistency under a unified time scale. If it's a split, it parses the sub-component descriptions in the attached component split list.

[0060] The event listener is deployed in the read / write event receiving buffer. For each batch of events (aggregated in 10-second windows), the tag key and event coordinates of the identity base table skeleton record are traversed. The spatial displacement of adjacent events is compared. If the displacement exceeds the preset threshold (selected by statistical analysis of historical data of hoisting paths on site, covering 98% of normal movement, such as 10 meters based on 500 operation records), a replacement detection is triggered. The split detection parses the XML format component segmentation list when the event type is "split" and extracts the list of geometric anchor points of the sub-components.

[0061] The detection results are output to a temporary buffer as a binary flag (replacement or splitting) to provide operation type confirmation for generating a new instance identifier. In the stacking and allocation after the replacement operation, this detection isolates abnormal signals to prevent the original instance identifier from continuing to receive irrelevant events that cause inventory position deviations.

[0062] 2.1: Generate a new instance identifier based on the identity evolution rules and open a new record in the identity base table.

[0063] Based on the detection results of the temporary buffer and the identity evolution rules (the versioning thresholds stored in the rule base, such as the minimum event continuity requirement for replacement being 3 reads and writes), a single new instance identifier is generated for the replacement operation, and multiple new instance identifiers corresponding to the component segmentation list are generated for the splitting operation. Then, a new record is created for each new instance identifier in the identity base table, and the model key, instance status and construction unit to which the original record belongs are copied, but the tag key is updated to the new value and the subsequent event field is set to empty.

[0064] The new instance identifier is generated using the original model key suffix incremental encoding, the formula is as follows: ,in This represents the original model key (a dimensionless string, converted to an integer hash value). The length of the sub-component number in the component segmentation list (dimensionless integer, ensuring unique extension). Indicates the sub-component number (dimensionless integer, starting from 1); for replacement, For splitting, the data is accumulated in the order of the list; when inserting a new record, a unified timestamp is used as the unique primary key, and the initial spatial index is recalculated based on the read and write pose of the new tag key to encode the quadtree.

[0065] The new instance identifier and the newly opened record in the identity base table form an initial binding list, providing a subordinate source for establishing the parent-child relationship table. This ensures that each child instance is recorded independently without losing model key inheritance and avoids deviations in aligning acceptance criteria with expired parent instances.

[0066] 2.3: Establish a parent-child relationship table to record the subordinate and substitution relationships between the new instance identifier and the original instance identifier.

[0067] Initialize the parent-child relationship table structure, which includes fields for parent instance identifier, child instance identifier, evolution type, trigger event identifier, evolution time, and evolution reason. For each new instance identifier in the initial binding list, insert a record where the parent instance identifier is taken from the model key of the original identity base table record, the child instance identifier is the newly generated value, the evolution type is labeled as "replace" or "split", the trigger event identifier is the unique ID of the read / write event triggered in the detection sub-step, the evolution time is a unified timestamp, and the evolution reason is the descriptive text extracted from the component splitting list or replacement signal.

[0068] Table insertions are performed using batch transactions to ensure atomicity; the evolution reason field is stored in JSON format, for example, {"reason":"Label damage replacement","details":"Original label key invalid"}; for splitting, a single parent record corresponds to multiple child records, and the child instance identifiers are arranged in the order of the component splitting list.

[0069] The parent-child relationship table is initially filled with subordinate records to provide genealogical anchors for the migration history area, establish locking replacement relationships, and avoid the chain of evidence being broken due to subsequent events being written to the original instance identifier that has expired.

[0070] 2.4: Move the original instance identifier to the history area and set the write status to frozen.

[0071] Based on the parent instance identifier of the parent-child relationship table, query the corresponding original record in the identity base table, copy it as a whole to the history area (an independent partition table with the same structure as the identity base table but with an added archive timestamp field), and set the write status field to "frozen" in the original identity base table record to prevent further event appending; the history area copy retains all fields, including the matching criteria and spatial index, but adds the frozen timestamp.

[0072] The migration operation uses SQL transactions, SELECT the original records from the identity base table INSERT the history area, and UPDATE the identity base table to set the write status. The freeze threshold confirmation is verified through the rule base. If the evolution type in the parent-child relationship table is "replacement" and the trigger event identifier has been confirmed, then it is executed; otherwise, it is rolled back.

[0073] The original instance identifier is isolated to the history area, and the identity base table is updated with a frozen flag. This provides a basis for status query for the receiving end to redirect. During the acceptance after the split, this migration ensures that the old records are only used for tracing and do not interfere with the current status progress, avoiding the deviation of quality inspection records being aligned to inactive instances.

[0074] 2.5: Redirection and lineage integrity records for executing freeze actions.

[0075] At the read / write event receiving end, for subsequent write requests targeting the original instance identifier, the child instance identifier in the parent-child relationship table is queried and the event is redirected to a new record in the corresponding new identity base table; at the same time, a redirection record field (expanding the table structure to include the redirection event identifier and redirection time) is added to the parent-child relationship table to ensure that the parent-child chain is unbroken in sequence under a unified time scale; for splitting, the redirection of multiple child instances is allocated according to the priority of the triggering event identifier.

[0076] The receiving end's interception logic embeds an event router. If the write status of the target instance identifier is frozen, it selects the parent-child relationship table to match the parent instance identifier and routes to the first unsaturated child instance identifier (saturation is defined as event writes exceeding a threshold, such as the daily limit of 50 times set in the rule base); the redirection record insertion formula is to append a timestamp. ,in Indicates the event timestamp. The network RTT (round-trip time, in seconds, measured in real time via a ping-like probe) is dynamically calculated, with an upper limit of 0.5 seconds, ensuring a uniform timescale deviation of <1%.

[0077] The parent-child relationship table is expanded into a complete genealogy, the redirection mechanism is activated, the event flow continues to new instances, and the inversion of causal sequence and the misalignment of spatial path evidence are avoided.

[0078] 2.6: Special registration and chain sequence maintenance for splitting operations.

[0079] If the detection result is split, then register an independent entry for each child instance in the parent-child relationship table according to the component split list, to ensure that the parent-child chain is arranged in the list order without any breaks under the same unified time scale; the order maintenance is verified by the incremental verification of the evolution time field. If the gap exceeds the threshold (determined by: selecting an interval that ensures 99% no delay, such as 1 second, based on the statistics of historical split events), then insert a virtual bridging node.

[0080] After parsing the list, batch INSERT the parent-child relationship table, sorting the evolution time by child component number; the bridging node only contains a timestamp and the "sequential bridging" reason, and does not affect the state progression.

[0081] The split genealogy is sequentially fixed in the parent-child relationship table, providing a seamless chain for the insertion of evolution nodes in the causal chain module, preventing tracing breakpoints between child instances, and ensuring the integrity of the subordinate transformation of the evidence chain.

[0082] The evolution and sealing module, through the chain-like connection of operation detection, new identifier generation, relationship table establishment, historical migration, reception redirection, and splitting of special registrations, constructs a parent-child relationship table and freezes the original instance identifier under the interference of replacement and splitting operations. This achieves continuous evolution of the identity genealogy and event redirection. In the material lifecycle at the construction site, this process maintains the unbroken traceability of the evidence chain, provides a stable parent-child path for the genealogy reflection integrity calculation of the mutual verification adjudication module, and avoids the identity deviation between the acceptance certificate and the actual installation object.

[0083] After the evolution and sealing module detects replacement or splitting operations, it generates a new instance identifier according to the identity evolution rules and opens a new identity base table record. It establishes a parent-child relationship table to record the subordinate relationship, moves the original instance identifier into the history area, freezes and writes it, and redirects subsequent events at the receiving end to form a complete genealogy. For splitting, it registers multiple sub-instances according to the component segmentation list to maintain the chain order without breaks.

[0084] The evolution and sealing module has generated new instance identifiers by detecting, replacing, and splitting operations. It locks the subordinate lineage and redirection mechanism in the parent-child relationship table to ensure that the event flow is stable and enters a new entry point after the original instance identifier is frozen. This avoids misidentification in the allocation of materials at the construction site. However, simple redirection is difficult to organize scattered read and write events into an ordered chain of evidence. As a result, the state changes and acceptance actions after hoisting and positioning cannot form a causal sequence with a true sequential relationship. This requires the causal chaining module to use the new instance identifier as the entry point, build an evidence chain list and insert evolution nodes. It generates a monotonic causal sequence through joint sorting and deduplication strategies, and then verifies it through a state machine. This connects all action nodes from arrival to acceptance, providing a continuous and reflectable sequence basis for the identity chain evidence of the mutual verification and adjudication module, and eliminating the impact of broken evidence chains on the credibility of collaborative management.

[0085] The specific processing logic of the causal chain module:

[0086] 3.1: Use the new instance identifier as the sole entry point to receive read and write events.

[0087] Monitor the read and write event stream. For each event, check whether the target instance identifier matches the new instance identifier of the newly opened record in the identity base table. If they match, capture the complete event data, including the event type, location index (event coordinate hash derived from the read / write point identifier), triggering terminal, and recording time. If they do not match, discard the event or route it to the exception queue (the exception queue outputs to the verification queue of the mutual verification decision as an additional input to the decision coefficient).

[0088] The ingress filter is deployed in the event receiving buffer. For each event batch (aggregated in 5-second windows), it queries the list of child instance identifiers in the parent-child relationship table as the valid ingress set, and the matching uses exact string comparison. The location index is calculated as the Z-order curve encoding of the event coordinates, using the formula... ,in The d-th dimension component of the event coordinates (unit: meters). Indicates the boundary range of the construction unit (unit: meters, the maximum side length predefined in BIM). Indicates the encoding bit width (dimensionless integer, fixed at 16 to cover the field scale).

[0089] The received read and write event sets are grouped and stored in a temporary buffer according to the new instance identifier, providing filtered and ordered input for the initial writing of the evidence chain. In the continuous operation scenario of outbound hoisting, this entry mechanism isolates irrelevant events, ensuring that only the evolved child instance receives targeted read and write data, and avoiding interference from residual signals of the parent instance on the continuity of state changes.

[0090] 3.2: Sort by event timestamp and write it into the evidence chain.

[0091] Extract the correction time (time stamp under a unified time scale) from the read and write event set of the temporary buffer, sort it in ascending order by correction time, and write it into the evidence chain list one by one. The chain list is initialized as a doubly linked list structure, which includes event identifier (auto-incrementing integer), target instance identifier, event type, location index, trigger terminal, record time and correction time fields; when writing, attach the head and tail pointers of the chain to support subsequent insertion.

[0092] The sorting algorithm is used to process batch events. The event identifier is generated by concatenating the correction time and the displacement of the triggering terminal ID (the displacement is the lower 8 bits of the terminal ID shifted to the right). The linked list is inserted from the tail to ensure time monotonicity. If the correction time conflicts, the position index is used as the secondary key for comparison.

[0093] The evidence chain initially forms a time-ordered node chain, preparing position anchors for the insertion of evolution nodes. During the multi-event aggregation process after storage, this write locks the original sequence record of read and write events, avoiding misalignment of action nodes caused by timestamp drift during the transfer process, and laying the foundation for the connection of subordinate conversion.

[0094] 3.3: Insert evolution nodes into the evidence chain table to connect evolution edges based on the parent-child relationship table.

[0095] Traverse the evidence chain list nodes, query the parent-child relationship table for the target instance identifier. If a matching child instance identifier exists and the evolution type is "replace" or "split", insert an evolution node before the corresponding node. The node type is "evolution", and it contains an evolution edge field pointing to the parent instance identifier and the evolution reason. The insertion position is precisely before or after the linked list position corresponding to the trigger event identifier.

[0096] The query uses an interval matching method between the evolution time of the parent-child relationship table and the correction time of the evidence chain list (evolution time ± threshold, where the threshold is determined by statistical analysis of historical evolution events, such as selecting a 1-second interval covering 99% of the delay based on 200 operation records); the evolution edges are encoded as a directed graph edge set, and the formula is... ,in Indicates the parent instance identifier. Indicates the sub-instance identifier. The evolution time is represented by the edge set, which is appended to the node metadata in the form of a tuple to ensure the unidirectionality of the edge direction from parent to child.

[0097] The evidence chain is expanded into a hybrid chain containing evolution nodes, providing subordinate edge information for joint sorting. This insertion bridges the parent-child lineage, ensuring that the evidence nodes of child instances can be traced back to the evolution trigger point, avoiding the deviation of acceptance actions being isolated from the parent history area.

[0098] 3.4: Generate causal sequences by combining chronological order and subordinate order.

[0099] For nodes with evolution edges in the evidence chain, a joint sorting key is applied to rearrange them: the primary key is the correction time, and the secondary key is the subordinate order (derived from the evolution time of the parent-child relationship table, with the parent having higher priority than the child). After sorting, a causal sequence is generated, which is organized by the instance dimension (new instance identifier group). The sequence nodes cover actions such as arrival, warehousing, warehousing, hoisting, positioning, acceptance, and evolution. The sequence edges indicate the actual order and subordinate transformation.

[0100] Formula for calculating bond ,in Indicates the calibration time. Indicate the subordinate order factor (e.g., 2^{32} to avoid overflow). This indicates the order of dependencies (parent instance is 0, child instances accumulate evolution depth); the sorting uses a stable topological sorting algorithm to handle edge dependencies, ensuring no cycles and that dependent edges are not reversed.

[0101] As an ordered graph structure output at the instance dimension, the causal sequence provides a monotonic chain for the deduplication strategy. In the cross action of placement and acceptance, this sorting integrates time and phylogenetic order to ensure that the sequence edges accurately reflect the subordinate transformation after hoisting and avoid the causal reversal between the outbound event and the installation event.

[0102] 3.5: Adjacent deduplication strategy is adopted for events that are repeatedly triggered by the same terminal within a short period of time.

[0103] Scan the causal sequence nodes, and check the event type, location index and triggering terminal triples of adjacent nodes. If they are completely identical within a short window (a threshold set in the rule base, such as a 2-second interval covering 95% of the jitter selected through on-site terminal response statistics), retain the first node and delete subsequent duplicates. Mark the deleted node as "duplicate" for traceability. After deduplication, the sequence remains monotonous and does not regress.

[0104] The triple hash is ,in Indicates the event type, Indicates the position index. Indicates the triggering terminal. The modulus is represented (fixed to 2^{64}-1 to ensure unique hashing); window checks compare pairs from the beginning of the sequence; deletion operations only remove pointers and do not change timestamps.

[0105] The causal sequence is simplified into a chain of nodes without redundancy, providing a clean input for state progression. In the noise of short-term repeated read and write operations, this deduplication filter removes terminal jitter, ensuring that the monotonicity of the sequence does not introduce false backtracking and avoiding the proliferation of abnormal nodes in the state machine progression.

[0106] 3.6: Perform state progression using instance state machines and handle progression failures.

[0107] Based on the node order of the causal sequence, the instance state machine is driven to advance: the state machine predefines the transition table of the preceding state, the trigger event type, and the following state (e.g., "Arrival" before "Inbound", "Stacking" after triggering "Inbound"); each node is verified, and if a match is found, the instance state field is updated; otherwise, the node is marked as an abnormal node and handed over to the consistency verification queue.

[0108] The verification process employs a finite state automaton, with a transition function. ,in Indicates the previous state. Indicates the event type, Indicates the subsequent state ( (For transfer mapping table lookup); if it fails, the abnormal node is appended with a correction time and a "progress failed" flag, and the queue is stored with a new instance identifier index.

[0109] Causal sequence verification is a stable chain after state advancement, providing anomaly markers for evidence reflection in the mutual verification adjudication module. During the complete action coverage process before acceptance, this advancement confirms the legality of sequence nodes, ensuring the integrity of the evidence chain of subordinate transformation and sequential relationship, and avoiding deviations in aligning quality inspection records to unverified states.

[0110] The causal chaining module, through entry reception, time-ordered writing, evolution node insertion, joint sorting generation, adjacent deduplication, and state machine advancement, forms a monotonic causal sequence covering all actions according to the instance dimension in the evidence organization of new instance identification. Under the dynamic installation process at the construction site, this processing connects the parent-child genealogy and the real boundary of state changes, ensuring the traceability of the evidence chain without backtracking, providing a continuous sequence basis for the projection of spatial path evidence, thereby eliminating the threat of causal inversion to the consistency of acceptance certificates.

[0111] The causal chaining module receives read and write events with a new instance identifier and writes them to the evidence chain list according to the timestamp. After inserting the evolution node, it sorts the time and subordinate order to generate a causal sequence. It applies triples to remove duplicates and maintain monotonicity, and verifies failed nodes by advancing the instance state machine.

[0112] The causal chaining module has constructed and jointly sorted the evidence chain list through new instance identification entry points, embedding evolution edges and state advancement verification in the causal sequence to form a single adjustment point chain and subordinate transformation relationship covering the on-site to acceptance actions. This provides a continuous traceability path for the identity chain evidence of materials at the construction site. However, when the spatial projection of read and write events exposes retrograde or crosses closed boundaries, the simple time sequence is difficult to verify the consistency of the real path, leading to an amplification of the reflection gap between the evidence chain list and the model connectivity relationship, which in turn causes the progress label and inventory location to diverge. This requires the mutual verification adjudication module to combine the parent-child genealogy reflection completeness and the consistency difference of the reachable path sequence at the consistency verification point to generate decision coefficients to trigger hierarchical backtracking correction, thereby defining the scope of influence and writing back the identity mapping table to ensure that the replaced and split acceptance certificate is aligned with the actual installation object, and strengthening the verifiability of the evidence chain in BIM collaborative management.

[0113] The specific processing logic of the mutual verification adjudication module:

[0114] 4.1: Perform genealogical expansion on the parent-child relationship table and construct a set of evolution paths.

[0115] The target instance identifier of the current instance is selected as the root node from the parent-child relationship table. The chain of parent instance identifiers and child instance identifiers is recursively traversed to expand the complete phylogenetic tree until the initial instance identifier is reached. Then, the tree structure is flattened into a set of evolution paths. Each path is an ordered sequence of nodes from the initial instance to the current instance. The nodes in the sequence contain the evolution time and evolution type.

[0116] The recursive unrolling uses a depth-first search, and the path termination condition is that the parent instance has no upstream or the evolution time is earlier than a unified timescale threshold (the threshold is determined by statistical analysis of historical genealogical data, such as selecting a starting timescale offset of 1 hour that covers 99% of the complete chain based on 300 evolution records); the path set is stored as a list, and each path is encoded in the form of a tuple (initial instance identifier, ..., current instance identifier) ​​to ensure that the acyclic traversal passes the incremental evolution time check.

[0117] The evolution path set is output as a flattened representation of the phylogenetic tree, providing subordinate chain anchors for one-to-one mapping with the evidence chain list. In the tracing of multiple sub-instances after splitting, this expansion locks the complete parent-child phylogenetic tree, avoiding the deviation of amplifying the gap segment from the root to the acceptance evidence.

[0118] 4.2: Reflect the evolution path set and the evidence chain one-to-one and mark the gap segments.

[0119] For each path in the evolution path set, the nodes are mapped to a subset of the evidence chain according to the evolution time interval. The matching criteria are the overlap between the target instance identifier and the correction time (the proportion of the number of path nodes covered by the node in the interval). Evolution segments that cannot be mapped (path nodes have no corresponding evidence nodes) are marked as gap segments, and the start and end evolution times of the gaps are recorded.

[0120] The echo uses dynamic programming matching, and the matching score is calculated using the following formula. ,in Indicates the evolution time of path nodes. This indicates the correction time of the nearest node in the evidence chain. Indicates the total number of path nodes. This indicates the time tolerance threshold (the upper limit of evolution delay set in the rule base, such as 5 seconds based on on-site operation statistics); if the score is lower than the preset standard, it is considered that it cannot be reflected, and the gap segment is appended to the path metadata as a binary interval (start time, end time).

[0121] The evidence replay annotation set contains a list of missing segments, providing a segmentation basis for the statistics of continuous replayable segments. It isolates the evidence missing areas through one-to-one mapping, ensuring that the hierarchical assessment of genealogical integrity does not ignore local breaks in the subordination process.

[0122] 4.3: The completeness level of the father-son genealogy is formed by the total number of continuous recognizable segments and the distribution of missing segments.

[0123] Summarize the evidence reflection annotation set, and count the total number of continuous reflectable segments (path subsequences without gaps) and the distribution of gap segments (number of gap segments divided by the total evolution path length); classify the levels according to the statistical results: full (no gaps), continuous (a single gap does not exceed 1 / 3 of the total length) and broken (multiple gaps accumulate to more than 1 / 2 of the total length), and the levels are recorded as dimensionless values ​​(full = 1.0, continuous = 0.5, broken = 0.0).

[0124] Segment count uses chain aggregation, distribution ratio ,in Indicates the number of gap segments. This represents the total evolution path length (total number of nodes); the level mapping is queried through the threshold table, if... Less than the preset standard and If it is continuous, it will be linearly decayed according to the cumulative ratio until it breaks, ensuring that the level value is in the range of [0,1].

[0125] The parent-child lineage reflection completeness is output as a single dimensionless level value, providing identity chain constraint parameters for calculating the consistency difference of reachable path order. In complex scenarios of outbound and in-place cross events, this forms a quantitative distribution impact of lineage gaps, avoiding the reflection evaluation from being biased towards the total number of segments and ignoring the severity of the break location.

[0126] 4.4: Extract elements from model instance information to construct reachable connectivity relationships and generate construction path sequences.

[0127] Extract the geometric anchor points and connectivity attributes of doors, stairs, freight elevators, unloading platforms and temporary passages from the model instance information, and construct an undirected graph connectivity relationship covering the construction units (nodes are anchor points, and edges are passages with reachable distances less than a threshold); then, for the last location point (event coordinates obtained by inverse solution of location index) of adjacent events in the evidence chain list and the current location point, generate the shortest construction path sequence, and use Dijkstra's algorithm to solve the path node chain.

[0128] The edge weights in the connected graph are Euclidean distances, and the threshold is set to the maximum channel width (predefined in BIM, such as 5 meters); the path sequence formula is a node chain. ,in This represents a candidate path (node ​​sequence). Indicates the distance between anchor points. This represents the path length; minimizing the total distance ensures shortest reachability.

[0129] The reachable path sequence set serves as the basis for spatial connectivity projection and provides graph constraints for the retrograde statistics of event location sequences. In the on-site layout where temporary passage changes occur, this generates and locks the legal path from unloading to installation, avoiding the risk of boundary crossings of elements such as freight elevators and stairs that are ignored in abstract connectivity.

[0130] 4.5: Project the sequence of event locations onto connectivity relationships and statistically analyze the consistency difference in reachable path order.

[0131] Project the event location sequence (location index sorted by correction time) in the causal sequence onto the reachable path sequence set, and calculate the projected path for each pair of adjacent locations; count the number of reverse travels (the number of edges in the projected path that increase in time but reverse in space) and the number of crossings across closed boundaries (the number of invalid edges of the path crossing the boundary fence of the construction unit), and locate the occurrence segment (the sub-interval of the path that reverses or crosses); form a dimensionless level value (low reverse travel, low crossing = 0, high value = 1) based on the two types of counts and the segment location (the proportion of the path from the initial location point).

[0132] Projection uses nearest neighbor mapping and backward counting. ,in The velocity vector of the q-th segment of the projected path is calculated by dividing the edge distance by the time difference. Indicates the time difference between adjacent events. Represents the number of projection segments, The indicator function is 1 for the reverse direction and 0 otherwise; the number of traversals is similar to counting closed edges, and the grade value is normalized by dividing the sum of the number of traversals by Q.

[0133] The reachability path sequence consistency difference, as a dimensionless rank value output, provides spatial deviation quantification for the upper limit constraint of the reachability falsification coefficient. In the vertical transfer of stairs and freight elevators, this statistic accurately locates the crossing section, ensuring that the consistency difference assessment captures the sequence threat of backtracking to the chain of evidence.

[0134] 4.6: The reachability falsification coefficient is calculated by using the consistency difference of reachable path order as the upper limit constraint.

[0135] Take the consistency difference of reachable path order as the upper limit of the decision coefficient. If the path involves reversals or crossings (number of times > 0), then the effective upper limit for the completeness of the parent-child lineage mapping is limited to [value missing]. ( (for the reflection level); within the restricted range [0, Within this range, the falsification coefficient can be obtained by linearly subdividing the reflection completeness, resulting in a single decision coefficient (the lower the value, the more consistent the result).

[0136] Constraint Formula ,in Indicates the completeness of the father-son genealogy (dimensionless [0,1]). It represents the consistency difference of reachable path order (dimensionless [0,1]); the min operation ensures that the upper limit takes effect, and the overall value is in the dimensionless interval [0,1], reflecting the strength of the falsification of the identity chain by the spatial deviation.

[0137] The decision coefficient, as the output of the comprehensive analysis, provides a single threshold basis for the division of the action domain. In the boundary of cross-unit hoisting, this comprehensive balance spectrum gap and path reversal avoid over- or under-checking caused by the dominance of a single parameter.

[0138] 4.7: Divide the action domain according to the decision coefficient and perform backtracking correction.

[0139] Action domains are divided by decision coefficient: loose domain (coefficient < 0.3, only register inconsistencies to the log and maintain identity base table mapping), correction domain (0.3 ≤ coefficient < 0.7, perform local backtracking), and strict control domain (coefficient ≥ 0.7, perform cross-construction unit backtracking). Backtracking correction is based on causal sequence, rollback to the previous consistent node (the nearest sequence node with decision coefficient < threshold), reconstruct the mapping relationship between label key and model key, and insert correction node (type "correction", including rollback time and new mapping) into the evidence chain.

[0140] Domain partitioning is achieved through if-else thresholding, and consistent node positioning is achieved by scanning the correction time in reverse from the current node; the historical mapping query and parent-child relationship table are reconstructed, and stable correspondences are restored first.

[0141] The backtracking correction node set is injected into the evidence chain list to provide a scope definition for the generation of correction records. In the case of multi-path interference before acceptance, this action isolates local deviations and ensures that the reconstructed mapping does not affect the evidence chain of irrelevant instances.

[0142] 4.8: Generate correction records and write them back to the identity mapping table.

[0143] For the backtracking and correction node set, a correction record is generated. This record includes the pre-correction mapping (original tag key-model key pair), the post-correction mapping (reconstruction pair), the trigger coefficient (decision coefficient), the set of events involved (rollback node ID list), and the scope of influence (list of affected construction units). Subsequently, the identity mapping table (extended from the identity base table, with added stable mapping fields) is written back in batches, updating the mapping relationship of the current instance and marking the last consistent node. Specific implementation: Records are stored in JSON structure, and the write-back uses transactional UPDATE to ensure atomicity; the scope of influence is extracted by deduplicating the construction units belonging to the set of events involved.

[0144] After this sub-step is completed, the identity mapping table is updated to the corrected version, and the correction record is archived to the log library. In the traceability requirements of settlement audit, this write-back solidifies the stable mapping and avoids the chain reaction of evidence deviation during the warranty period.

[0145] The mutual verification adjudication module integrates spectral expansion and reflection, reachable path projection statistics, falsification coefficient synthesis, action domain backtracking and mapping rewriting at the hierarchical level. At the consistency check point, it integrates identity chain and spatial path evidence to generate decision coefficients, achieving bounded correction and scope definition. Under the interference of reverse crossing at the construction site, this process ensures the consistency between the rollback reconstruction of the causal sequence and the identity mapping, providing a verification basis for the iterative archiving module, thereby eliminating the risk of irreversible breakage of the basis for quantity acceptance.

[0146] The mutual verification adjudication module calculates the difference between the completeness of the parent-child genealogy and the consistency of the reachable path order, and then synthesizes them to form the reachability falsification coefficient. Based on the decision coefficient, the action domain is divided to perform hierarchical backtracking correction, generate correction records, and write back to the identity mapping table.

[0147] The mutual verification adjudication module has used action domain division and backtracking correction of decision coefficients to integrate identity chain and spatial path evidence at the consistency check point to generate correction records and write back identity mapping tables, ensuring the local reconstruction of causal sequences and the definition of the scope of influence. This maintains the homogeneity of the evidence chain under the interference of reverse crossing at the construction site. However, static rules are difficult to adapt to the dynamic evolution of temporary channel changes or spectrum gap distribution during continuous operation, resulting in slow convergence of subsequent batch mappings and accumulation of acceptance certificate deviations. This requires the iterative archiving module to summarize the verification results and correction records within the continuous operation window, perform version updates of identity evolution rules and export verification output, and solidify the archiving unit to provide a stable starting point. This enables adaptive optimization of rules and version solidification of the evidence system in the settlement and quality assurance scenario of the entire life cycle of materials, strengthening the long-term verifiability of collaborative management.

[0148] The specific processing logic of the iterative archiving module:

[0149] 5.1: Summarize the consistency verification results and correction records.

[0150] When the continuous running window (a batch cycle defined in the rule base, such as triggered at the end of each day) is started, the verification results (including decision coefficients, completeness of reflection and consistency difference level) and correction records (mapping before correction, set of events involved, etc.) output by the aggregated mutual verification adjudication module are combined to form a summary dataset. The dataset is grouped by new instance identifier and additional statistical metadata such as total number of corrections and average decision coefficients are added.

[0151] Aggregation uses subtractive cumulative counting, statistical formula ,in Let represent the decision coefficient of the i-th record (dimensionless [0,1]). Indicates the total number of correction records. This represents the correction domain threshold (dimensionless 0.3, fixed in the rule base). The indicator function is 1 if the threshold is exceeded, otherwise 0; grouping uses a hash table with the new instance identifier as the key to ensure that the dataset covers the current instance set.

[0152] The aggregated dataset serves as the input source for rule updates, providing quantitative deviation indicators for iterative optimization. During continuous operation across multiple batches within the warranty period, the aggregated dataset captures cumulative correction patterns, preventing isolated verification results from ignoring the trend of long-term path consistency differences.

[0153] 5.2: Perform iterative updates and versioning of the identity evolution rules.

[0154] Based on the statistical metadata of the aggregated dataset, the identity evolution rules are updated item by item for the following: replacement and splitting trigger boundaries (adjusting minimum event continuity requirements), tolerance boundaries for phylogenetic gaps (upper limit of the expansion gap ratio), boundary adjustments for read / write point coverage areas (radius increases or decreases based on the number of crossings), and temporary channel changes in connectivity relationships (temporary channel changes subscribe to model instance information update events in real time via the BIM API, and the changed anchor points are automatically injected into the connectivity graph, triggering incremental rule version updates instead of full reconstruction). After the update, a new version number (incrementing integer) is generated, written to the rule version repository, and the effective version is recorded for the current instance in the identity mapping table.

[0155] Boundary adjustment uses proportional expansion, formula ,in This represents the original boundary value (a dimensionless ratio, such as 0.33). This indicates the updated boundary (dimensionless ratio). This indicates a corrected count (dimensionless integer). The total number of records (dimensionless integer) is represented, and the proportion term reflects the deviation density for adaptive expansion. Version writing uses transaction commit, the library structure is a key-value pair (version number, rule JSON), and the identity mapping table UPDATE adds the effective version field.

[0156] The identity evolution rules are updated to a new version set, and the rule version library expands the records to provide optimized constraints for exporting credentials. In the evolution of the on-site layout with frequent changes in temporary channels, this iteration locks the adaptive threshold to ensure the dynamic convergence of the split trigger boundary without introducing excessive leniency.

[0157] 5.3: Export the verified mapping table and acceptance certificate from the current instance set.

[0158] Traverse the current instance set (selecting new instance identifiers with non-frozen write status from the identity base table), and derive the mapping table based on the stable mapping of the identity mapping table, the evolution path summary (a brief description of the path set extracted from the parent-child relationship table), and the last consistent node (the sequence node after backtracking correction); at the same time, generate an acceptance certificate, which includes the instance status, the evidence chain summary (the causal sequence node coverage summary), and the replay description (the replay completeness level description).

[0159] Exporting uses serialized JSON, with the path digest length limited to the first three generations of parent-child chains (based on evolution time truncation); credential verification is performed through cross-checking, and a warning flag is added if the stable mapping does not match the evidence chain digest, ensuring that the output file is named with the new instance identifier.

[0160] The mapping table and acceptance certificate serve as a set of verification output files, providing a solidification of results for archiving. This export integrates the last consistent node and the feedback description to ensure that the certificate aligns with the evidence chain summary of the actual installed object, avoiding version drift of quality inspection records.

[0161] 5.4: Perform current batch archiving and generate a stable starting point.

[0162] For the current batch, capture snapshots of the identity base table (full table dump), parent-child relationship table, evidence chain list, identity mapping table, and rule version number to form an archive unit; the snapshots are stored in the version control repository and indexed by batch ID (unified timestamp hash). After archiving is completed, mark the end of the continuous running window and set it as the stable starting point for preloading the next batch (latest snapshot pointer).

[0163] Snapshot capture uses a database dump tool to ensure atomic consistency; batch ID generation formula. ,in Indicates the unified timestamp at the end of the window. For SHA-256 digest (dimensionless bytes converted to integer), modulo Folded into a 32-bit ID.

[0164] The archived unit is fixed in the library, and the stable starting point pointer is updated. At the beginning of the next batch of incoming stacking, this execution isolates historical deviations and ensures that the cumulative effect of rule iteration does not interfere with the double-bond alignment of new events.

[0165] The iterative archiving module, through the orderly connection of verification and summary, rule iterative update, verification export and batch archiving, version-fixed identity evolution rules and evidence snapshots within the continuous running window. Under the dynamic material management of the construction site, this process adaptively optimizes the trigger boundary and fault tolerance parameters, and outputs mapping tables and vouchers to support settlement auditing, thereby providing a breakpoint-free starting point for subsequent batches and eliminating the long-term threat of version drift to collaborative credibility.

[0166] The iterative archiving module summarizes the consistency verification results and correction records, iteratively updates the identity evolution rules and records them in a versioned manner, exports the verified mapping table and acceptance certificate, and archives the current batch snapshot to form a stable starting point.

[0167] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0168] It should be noted that the system of the present invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting a variety of hardware environments and usage requirements.

[0169] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0170] It should be noted that, in this document, the use of relational terms such as "first" and "second" is merely to distinguish one entity or operation from another, and does not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0171] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A construction site material RFID tracking and BIM collaborative management system, characterized in that, include: Identity mapping module: Collects tag events and model instance information under a unified time scale, generates an identity base table and establishes a correspondence between tag keys and model keys, and marks the instance status and its construction unit; Evolution and archiving module: When a replacement or split operation occurs, a new instance identifier is generated according to the identity evolution rules and a parent-child relationship table is established. The original instance identifier is transferred to the history area and event writing is stopped. Causal Chaining Module: Receives read and write events with the new instance identifier as the unique entry point and writes them into the evidence chain list. The evidence chain list organizes parent-child relationships and state changes in chronological order to form a causal sequence. Mutual verification adjudication module: At the consistency verification point, the corresponding backtracking method is selected based on the comprehensive analysis results of identity chain evidence and spatial path evidence, the scope of correction is defined, and a correction record is generated and the identity mapping is written back. Iterative archiving module: In the continuous running window, the identity evolution rules are iteratively updated based on the consistency verification results and correction records, and the verified mapping table and acceptance certificate are output and archived for the current batch.

2. The construction site material RFID tracking and BIM collaborative management system according to claim 1, characterized in that: The identity mapping module uses a unified time stamp to calculate the time offset for each source and correct the event timestamp based on a reference clock. It uses the tag key, read / write point identifier, read / write pose, event type, and event coordinates in the tag event as fields, and combines them with the model key, instance status, construction unit, instance geometric anchor point, and instance coordinates in the model instance information to generate an identity base table.

3. The construction site material RFID tracking and BIM collaborative management system according to claim 2, characterized in that: The identity mapping module establishes a correspondence by performing precise matching of the tag key in the historical mapping table. If no match is found, candidate model keys are filtered based on the principle of minimizing the reachable distance from the instance's geometric anchor point to the event coordinates. Then, a unique model key is obtained by consistent trimming based on the construction unit boundary and the read / write point coverage area. This unique model key is written into the identity base table and the instance status and its associated construction unit are marked.

4. The construction site material RFID tracking and BIM collaborative management system according to claim 1, characterized in that: The evolution and sealing module detects replacement or splitting operations, generates new instance identifiers based on identity evolution rules, and creates new records in the identity base table. It also establishes a parent-child relationship table to record the subordinate and replacement relationships between the new instance identifier and the original instance identifier. The parent-child relationship table records the parent instance identifier, child instance identifier, evolution type, trigger event identifier, evolution time, and evolution reason.

5. The construction site material RFID tracking and BIM collaborative management system according to claim 4, characterized in that: The evolution and sealing module moves the original instance identifier into the history area and sets the write status to frozen. The freezing action is executed on the receiving end to redirect the subsequent event write request targeting the original instance identifier to the new instance identifier. The redirection is recorded in the parent-child relationship table to form a complete genealogy. If it is split, multiple child instance identifiers are registered in the parent-child relationship table according to the component split list. The parent-child chain maintains the order without breakpoints under the same time scale.

6. The construction site material RFID tracking and BIM collaborative management system according to claim 1, characterized in that: The causal chaining module receives read and write events with the new instance identifier as the unique entry point, sorts them according to the event timestamp, and writes them into the evidence chain list. Based on the parent-child relationship table, it inserts evolution nodes into the evidence chain list to connect evolution edges. Then, it generates a causal sequence by jointly sorting the time order and the subordinate order. The causal sequence is organized by instance dimension, and the sequence nodes cover the actions of arrival, warehousing, warehousing, hoisting, positioning, acceptance, and evolution. The sequence edges indicate the actual sequence relationship and subordinate transformation.

7. The construction site material RFID tracking and BIM collaborative management system according to claim 6, characterized in that: The causal chaining module uses an adjacent deduplication strategy for events repeatedly triggered by the same terminal within a short period of time. The deduplication rule is based on the triple of event type, location index and terminal identifier. The deduplicated sequence remains monotonic and does not backtrack. After the causal sequence is generated, the state is advanced using an instance state machine. The state advancement indicates the determined previous state, triggering event type and subsequent state. If the advancement fails, an abnormal node is marked in the evidence chain list.

8. The construction site material RFID tracking and BIM collaborative management system according to claim 1, characterized in that: The mutual verification adjudication module calculates the completeness of the parent-child genealogy at the consistency check point, performs genealogy expansion on the parent-child relationship table to construct an evolution path set from the initial instance to the current instance, and performs one-to-one mapping between the path set and the evidence chain. Unrecorded evolution segments are marked as gap segments, and the total number of continuously recognizable segments and the distribution of gap segments form a hierarchy.

9. The construction site material RFID tracking and BIM collaborative management system according to claim 8, characterized in that: The mutual verification adjudication module calculates the consistency difference of reachable path order. It extracts doors, stairs, freight elevators, unloading platforms and temporary passages from model instance information to construct reachable connectivity relationships covering construction units, generating a construction path sequence from the previous location point to the current location point. It projects the event location sequence in the evidence chain onto the connectivity relationship, counts the number of reverse traversals and the number of crossings of closed boundaries, and locates the occurrence segment. The decision coefficient is obtained by combining the two with the reachability falsification coefficient.

10. The construction site material RFID tracking and BIM collaborative management system according to claim 1, characterized in that: The iterative archiving module summarizes the consistency verification results and correction records within the continuous running window. It performs iterative updates on the identity evolution rules, including replacing and splitting trigger boundaries, fault tolerance boundaries for genealogical gaps, boundary adjustments for read / write point coverage areas, and temporary channel changes in connectivity relationships. Updates are written to the rule version repository in a versioned manner and the effective version is recorded in the identity mapping table. The current batch is archived, including snapshots of the identity base table, parent-child relationship table, evidence chain list, identity mapping table, and rule version number.

Images