An IoT-driven BIM model incremental updating method based on component-level differential encoding

Abstract

The application discloses an IoT-driven BIM model incremental updating method based on component-level differential coding, relates to the technical field of computer three-dimensional figure rendering and Internet of Things digital twin, and comprises the following steps: performing weighted calculation on components in a BIM model based on component types, business labels, associated IoT measuring point change frequencies and geometric independence to obtain dynamic scores, and dividing the dynamic scores into a static component set and a dynamic entity set according to a threshold value; publishing the static component set as 3DTiles static slices; and publishing the dynamic entity set as independent glb or gltf files. Through dynamic score classification and unified identification mapping, the application realizes IoT data rapid positioning and millisecond-level updating; adopts a differential dirty area redrawing mechanism to stabilize a frame rate; utilizes identification decoupling to guarantee long-term operation and maintenance reliability; independently controls dynamic objects to improve attitude reliability; and is compatible with CesiumJS and three.js, and has good engineering landing performance.

Description

Technical Field

[0001] This invention relates to the fields of computer 3D graphics rendering and Internet of Things (IoT) digital twin technology, specifically to an IoT-driven incremental update method for BIM models based on component-level differential coding. Background Technology

[0002] In digital twin applications such as smart parks, energy stations, industrial plants, and data centers, Building Information Modeling (BIM) is typically published in streaming formats such as 3DTiles and glTF / glb, and loaded and visualized through a front-end 3D engine. To improve the loading efficiency and rendering performance of large-scale models, existing technologies usually perform lightweight processing on the BIM model on the server side, including model merging, slicing, Level of Detail (LOD) construction, and spatial index optimization. The client then loads the model on demand based on view frustum, distance, and screen error. However, under this processing method, the sliced ​​and merged BIM components are usually baked into a static data structure, making it difficult to control their spatial position and orientation individually like independent nodes in a traditional 3D scene. At the same time, device status, alarm information, and measurement point data in Internet of Things (IoT) systems have high-frequency changes and real-time characteristics. Existing systems mostly attach IoT data to the 3D scene through 2D interface overlay or simple binding, lacking the ability to fine-grained drive the model components.

[0003] Existing technologies for integrating IoT data with BIM models have several shortcomings: First, the boundaries between static tile models and dynamic business objects are unclear. Some solutions assume that BIM components can be independently adjusted in pose on the client side, but in reality, components within a tile often cannot be controlled individually, leading to update commands failing. Second, the relationships between various identifiers such as IoT device IDs, BIM component IDs, and featureIds in 3DTiles are complex and lack unified standards, making it difficult to support long-term operation and maintenance. Third, model data, business attributes, and real-time status are mixed in the same update process, making it impossible for the front end to distinguish between different types of updates, thus increasing the computational burden and affecting rendering performance. In addition, the functions of the presentation layer are scattered, with color, transparency, alarm flashing, and dynamic pose handled by different modules, lacking unified rules and easily causing display inconsistencies. Finally, objects that require dynamic pose changes are still included in static tiles, making it impossible for the client to reliably drive their movement, resulting in obvious stuttering and frame drops, which seriously affects the system's real-time performance and visualization effects.

[0004] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to provide an IoT-driven incremental update method for BIM models based on component-level differential coding, so as to solve the problems in the background art mentioned above.

[0006] To achieve the above objectives, the present invention provides the following technical solution: an IoT-driven incremental update method for BIM models based on component-level differential coding, comprising the following steps: The components in the BIM model are weighted based on component type, business tag, frequency of change of associated IoT measurement points and geometric independence to obtain dynamic scores, and are divided into static component sets and dynamic entity sets according to thresholds. The static component sets are published as 3DTiles static tiles, and the dynamic entity sets are published as independent glb or gltf files. Generate unified identifiers for static component sets and dynamic entity sets, and establish mapping relationships between IoT device identifiers, measurement point identifiers, BIM component identifiers, 3DTiles feature identifiers, and dynamic entity identifiers; The target set is located based on the mapping relationship. The value of the IoT data packet is compared with the current state of the corresponding target. When there is a difference, a differential data packet containing the target identifier, change type, change value and version number is generated. The object type is determined according to the target identifier in the differential data packet. The display attributes in the graphics processing unit's video memory are updated for static components, and the transformation parameters or animation status are updated for dynamic entities. Version control is implemented for differential data packets. When out-of-order or missing packets occur, they are discarded or compensated. If compensation fails, a snapshot of the current state of the target is obtained to update the cache. When the loss rate exceeds the threshold, the system switches to periodic polling mode.

[0007] Preferably, the dynamic score is calculated using the following weighted expression: In this formula, the parameters have the following meanings: This represents the BIM component object to be evaluated; Representation of components The dynamic score is used to measure whether it is suitable to be classified as a dynamic entity; The weighting coefficients corresponding to the four types of evidence satisfy the following constraints: The weight values ​​range from 0 to 1 and are used to adjust the degree of influence of different pieces of evidence on the final score. The four types of decision functions are all indicators, taking values ​​of 0 or 1, used to indicate whether the corresponding condition is true or false. The specific definitions of the four types of decision functions are as follows: Type of evidence: in, The BIM type identifier for the component. This represents a predefined set of active types, such as IfcDoor, IfcValve, IfcActuator, and IfcDamper. Business evidence: Among them, the business tag is used to describe the functional role of the component in the actual project. This evidence is used to make up for the problem that relying solely on the Ifc type cannot accurately express business behavior. Behavioral evidence: in, This indicates the frequency of change in IoT measurement point data associated with the component. The frequency threshold is used to determine whether the changes at the measuring points have reached a level of frequent change; this evidence reflects whether the component has a continuous dynamic update requirement during operation. Geometric evidence: This criterion is used to evaluate whether a component has the ability to be independently extracted from the slice model at the geometric level, and it is particularly critical for components that have been merged or baked into the overall mesh; After completing the scoring calculation, the classification is based on the following judgment rules: in: It is a dynamic threshold used to control the classification boundary; This is the component classification result, with values ​​of dynamic or static. Dynamic means that the component is stripped into an independent GLB or GLTF dynamic entity, which can be controlled in position, pose and animation at runtime. Static means that the component is retained in the 3DTiles static slice, only participating in the overall rendering, and does not undergo independent pose updates.

[0008] Preferably, the composite mapping performs conflict handling according to the following rules during the parsing process: when multiple measurement points are mapped to the same component, the data source with the highest priority is selected according to the preset priority; when a measurement point is mapped to multiple components, fan-out is performed in a one-to-many manner; when no priority is configured, the Last-Writer-Wins rule is adopted, and the one with the larger timestamp overwrites the one with the smaller timestamp.

[0009] Preferably, during the version-snapshot consistency maintenance process, each differential data packet carries a monotonically increasing version number, and the front-end processor maintains a known maximum version number for each target; when a newly arrived version number is less than or equal to the maximum version number, it is determined to be a duplicate or out of order and is discarded; when the version number is greater than the maximum version number plus one, it is determined to be missing and a timed packet replacement request is triggered; when the packet replacement request times out and does not respond, a complete state snapshot of the corresponding target is obtained from the server to overwrite the local cache.

[0010] Preferably, the complete state snapshot only contains the current state value and timestamp information, but does not contain model geometric data. When the cumulative loss rate of differential data packets exceeds a preset threshold within the sliding window, it switches to a periodically executed full polling mode, and automatically switches back to differential update mode after returning to normal.

[0011] Preferably, during the layered execution of rendering instructions, dynamic entities are constructed using the instantiation rendering method of the graphics processing unit. Multiple dynamic entities of the same type share the same geometric data, store their respective instance attribute buffers only in video memory, and only mark the affected instances as dirty data. In the next frame, only the corresponding pixel area is redrawn.

[0012] Preferably, static components are updated in state through the attribute buffer in the graphics processing unit's video memory, and the video memory cache of the static slice model remains unchanged during state changes, so as to avoid repeated loading or reconstruction of the model's geometric data.

[0013] The technical effects and advantages provided by the present invention in the above technical solution are as follows: This invention avoids the problem of full traversal of the front-end scene graph in traditional solutions by introducing a static and dynamic classification mechanism based on dynamic scoring and a unified identifier mapping system in the IoT data-driven process. Upon arrival of IoT data, the target object can be quickly located directly through the mapping index, and the corresponding update path can be entered according to the object type, achieving constant-time data location and processing. This approach significantly reduces the computational overhead of a single state update, enabling the system to maintain millisecond-level response capabilities even under high-frequency data input conditions, thus improving overall real-time performance.

[0014] This invention employs a rendering strategy combining differential driving and dirty region updates. It only marks and triggers local redraws for objects that have changed, while maintaining the static layer memory cache unchanged. By reducing unnecessary global refresh operations, it effectively lowers the GPU computational burden, making the rendering process unaffected by high-frequency data fluctuations in IoT, thus stably maintaining a high frame rate output. This mechanism can consistently guarantee a smooth visual experience under complex scenes and large-scale model conditions.

[0015] This invention achieves unified management of IoT device identifiers, BIM component identifiers, and rendering layer identifiers through a decoupled design of identifier standardization and composite mapping, and persistently stores the mapping relationships. During long-term operation and maintenance processes such as model tile reconstruction, device replacement, or professional segmentation, this mechanism ensures the stability of the identifier system, preventing the loss of association relationships due to changes in model structure, thereby improving the system's maintainability and scalability.

[0016] This invention achieves precise control over position, pose, and animation by separating objects requiring pose changes from static slices into independent dynamic entities and combining this with an update method that directly operates on the object handle. Simultaneously, a dirty area redrawing strategy reduces the involvement of irrelevant objects in calculations, resulting in more stable performance of dynamic devices during operation, significantly reducing frame drops and stuttering, and improving the reliability of dynamic performance.

[0017] This invention is compatible with mainstream 3D rendering engine environments at the implementation level, providing corresponding interface implementation paths under the CesiumJS and three.js frameworks, covering key capabilities such as static property updates and dynamic transformation control. This design does not rely on any commercial closed-source platform, possesses excellent engineering feasibility and cross-platform adaptability, and can be quickly deployed and run stably in various practical application scenarios. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0019] Figure 1 This is a schematic diagram of the overall system architecture of the present invention.

[0020] Figure 2 This is a schematic diagram of the IoT data composite mapping and conflict resolution process of the present invention.

[0021] Figure 3 This is a schematic diagram of the component state difference generation process of the present invention.

[0022] Figure 4 This is a schematic diagram of the component state machine and state transition relationships of the present invention.

[0023] Figure 5 This is a schematic diagram of the rendering timing process driven by multi-source IoT data in this invention. Detailed Implementation

[0024] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the description of this disclosure will be more complete and fully convey the concept of the exemplary embodiments to those skilled in the art.

[0025] This invention provides Figures 1-5 The method for incremental updating of BIM models driven by IoT based on component-level differential coding, as shown, includes the following: Before the model is published, each component in the BIM model needs to be finely classified into two categories: static components and dynamic entities, to determine its load-bearing level in the subsequent system. Static components are uniformly processed within 3DTiles static tiles and do not require individual pose adjustments after loading, thus ensuring rendering stability for large-scale scenes. Dynamic entities are exported independently as GLB or GLTF files and are individually controlled by the front end during runtime, enabling real-time driving of position, pose, and animation. This classification mechanism forms the foundation for the effective operation of subsequent IoT data-driven, differential updates, and layered rendering, directly affecting the reliability and performance of runtime control.

[0026] Simply relying on component type for classification is insufficient to meet actual engineering needs, because whether a component moves depends not only on its semantic category but also on its usage and geometric structure. For example, among components belonging to the valve category, some remain fixed and only perform structural functions, while others frequently open and close during operation, exhibiting significant dynamic behavior. Furthermore, while some components may semantically possess motion attributes, their geometry may have been integrated with the surrounding structure during modeling or slicing, making independent separation at the graphical level impossible. Based on these considerations, a multi-dimensional evidence weighting mechanism is introduced to comprehensively evaluate type characteristics, business labels, IoT measurement point change frequency, and geometric independence. This helps avoid misjudgments, achieving classification results that better reflect engineering realities, thus providing reliable support for subsequent dynamic driving and rendering optimization.

[0027] During the model preprocessing stage, while the server performs operations such as lightweighting, merging, slicing, level of detail (LOD), and spatial indexing on the original BIM model, it is necessary to quantitatively evaluate each component to determine whether it requires independent dynamic control. This evaluation process uses dynamic score as the core metric and achieves fine-grained classification of component attributes through comprehensive calculation of multi-dimensional evidence, thereby avoiding misjudgment problems caused by a single rule.

[0028] The dynamic score is calculated using the following weighted expression: In this formula, the parameters have the following meanings: This represents the BIM component object to be evaluated; Representation of components The dynamic score is used to measure whether it is suitable to be classified as a dynamic entity; The weighting coefficients corresponding to the four types of evidence satisfy the following constraints: The weight values ​​range from 0 to 1 and are used to adjust the degree of influence of different pieces of evidence on the final score. There are four types of decision functions, all of which are indicators, taking values ​​of 0 or 1, used to indicate whether the corresponding condition is true or false.

[0029] The specific definitions of the four types of decision functions are as follows: Type of evidence: in, The BIM type identifier for the component. This represents a predefined set of active types, such as IfcDoor, IfcValve, IfcActuator, and IfcDamper.

[0030] Business evidence: Among them, the business tag is used to describe the functional role of the component in the actual project. This evidence is used to make up for the problem that relying solely on the Ifc type cannot accurately express business behavior.

[0031] Behavioral evidence: in, This indicates the frequency of change in IoT measurement point data associated with the component. This is a frequency threshold used to determine whether changes at the measurement points have reached a level of frequent variation. This evidence reflects whether the component has a continuous dynamic update requirement during operation.

[0032] Geometric evidence: This criterion is used to evaluate whether a component has the ability to be independently extracted from the slice model at the geometric level, and it is particularly critical for components that have been merged or baked into the overall mesh.

[0033] After completing the scoring calculation, the classification is based on the following judgment rules: in: It is a dynamic threshold used to control the classification boundary; This is the component classification result, with values ​​of dynamic or static. Dynamic means that the component is stripped into an independent GLB or GLTF dynamic entity, which can be controlled in position, pose and animation at runtime. Static means that the component is retained in the 3DTiles static slice, only participating in the overall rendering, and does not undergo independent pose updates.

[0034] The aforementioned method comprehensively models four dimensions: type features, business semantics, operational behavior, and geometric structure, avoiding the limitations of traditional single-type judgment methods. For example, some components may semantically belong to the movable category, but in actual engineering, they remain in a fixed state for a long time, or their geometric structure cannot be independently separated. In such cases, introducing geometric and behavioral evidence as constraints can effectively reduce the risk of misjudgment. Furthermore, the weight parameters and thresholds are adjustable engineering parameters, which can be flexibly configured according to the density of IoT measurement points, professional divisions, and model size in different projects, thereby achieving stable and consistent classification results in different application scenarios.

[0035] This dynamic scoring mechanism enables fine-grained partitioning at the component level, providing a reliable data foundation for subsequent differential updates and layered rendering. It ensures that only objects with truly dynamic requirements are processed during runtime, thereby improving the overall system response performance and stability while maintaining rendering efficiency.

[0036] To further illustrate the judgment process of the dynamic scoring model in actual engineering, the calculation logic can be explained through typical component examples. The following examples are only for explaining the calculation method and do not limit the specific parameter values.

[0037] First, regarding the frequently opened and closed regulating valve component, its dynamic evaluation results are as follows: the component's type in the BIM model belongs to the preset set of easily movable types, thus satisfying the type evidence condition, i.e. At the same time, its business label clearly identifies it as a valve, which belongs to the category of movable equipment, thus meeting the business evidence requirements, namely... Furthermore, this component is associated with frequently reported IoT measurement points, and its frequency of change meets a threshold condition, namely... In terms of geometry, this component can be independently separated from the overall model, and its geometric bounding box is independent, thus satisfying the geometric evidence condition, namely... If all four pieces of evidence are valid, the dynamic rating is: Because the scoring result meets the judgment criteria: Therefore, the classification result is: The component is isolated as an independent GLB model, which can be driven by IoT data (such as opening information) to change its rotation or attitude during operation.

[0038] Secondly, regarding load-bearing wall components, their dynamic assessment is as follows: These components do not belong to the easily movable type set, therefore... Its business attributes do not include the movable equipment tag, therefore At the same time, no IoT measurement points were associated, or the frequency of measurement point changes did not reach the threshold, therefore Although this component may be geometrically separable, this feature alone is insufficient to support its function as a dynamic object. Therefore, the score is obtained: Under normal configuration, this value is less than the threshold: Therefore, the classification result is: This component is retained in the 3DTiles static slice and only participates in the overall rendering without being subject to independent dynamic control.

[0039] Furthermore, for normally open process valves whose geometry has been merged or baked and cannot be independently separated, their dynamic evaluation exhibits more complex characteristics. This component meets the conditions at both the type and business label levels, therefore: However, it is not associated with high-frequency IoT measurement points: At the same time, because the geometric structure has been integrated with the surrounding components, it cannot be extracted independently: Therefore, its rating is: In this case, the final classification result depends on the parameter configuration. When the weights... Larger or threshold Setting higher At that time, there were: Therefore, we get: This process avoids performing invalid pose control on geometric objects that cannot be separated independently, thereby reducing rendering resource waste and potential errors.

[0040] The above examples illustrate the specific roles of each parameter in dynamic assessment: : These represent the weights of typological evidence, business evidence, behavioral evidence, and geometric evidence, respectively, and are used to adjust the influence ratio of different dimensions in the comprehensive judgment; : Indicates whether the corresponding evidence is valid, and takes the value of 0 or 1; The comprehensive scoring results are used to quantify the dynamic property strength of the components. : Judgment threshold, used to distinguish between dynamic entities and static components; : Classification result identifier, with values ​​of dynamic or static.

[0041] In particular, the decision terms corresponding to geometric separability It plays an independent and crucial role in the overall evaluation system. This indicator can effectively distinguish components that have semantic motion attributes but cannot be independently controlled in engineering, thus avoiding misclassification problems caused by geometric constraints. By incorporating geometric features into the scoring system, the limitations of relying solely on type or business labels can be overcome, making the classification results more consistent with actual engineering constraints.

[0042] By using the weighted combination of the aforementioned multidimensional evidence, parameter configurations can be flexibly adjusted in different application scenarios to achieve fine control over the dynamic attributes of components, providing stable and reliable basic data support for subsequent differential updates and layered rendering.

[0043] In complex BIM model and IoT data fusion application scenarios, the consistency and stability of component identification directly affect the reliability of subsequent mapping relationships and long-term operation and maintenance effectiveness. During model deployment, operations such as lightweighting, geometric merging, slicing, and hierarchical reconstruction may occur, often resulting in the original BIM component identification not being fully preserved on the rendering side, or even being lost, rearranged, or untraceable. Therefore, it is necessary to establish a unified and stable identification system for both static components and dynamic entities to support subsequent data association and state-driven operations.

[0044] During the identifier generation process, a unique identifier based on the UUIDv5 algorithm is introduced for each component or entity. This algorithm generates deterministic results by combining the namespace with the original identifier, thus ensuring that the same identifier can be repeatedly generated under the same input conditions. The namespace adopts a combination of project ID and professional ID, which gives the identifiers natural isolation in cross-project or cross-professional environments, avoiding identifier conflicts between different projects or different professions. At the same time, this method can maintain the stability of the identifiers when the model is repeatedly built or updated, without depending on the specific geometric structure or file organization.

[0045] The generated UUIDs are managed uniformly along with the existing multi-source identification information, including BIM component IDs, professional codes, featureIds or batchIds in 3DTiles, and IDs corresponding to dynamic entities. These identifiers are organized and stored in a persistent mapping table, forming the data foundation for multi-dimensional relationships. The persistent storage method ensures that the mapping relationships can be accurately restored during system restarts, version iterations, or data migrations, avoiding inconsistencies caused by runtime temporary generation.

[0046] This mechanism effectively solves the problem of broken identification chains in the model processing flow. For example, during the slicing process, multiple components may be merged into a single rendering unit, and the original component-level IDs are no longer directly visible, but the original business object can still be traced back through the mapping table. After lightweighting or LOD processing, even if the geometric expression changes, the identification system remains stable, thus ensuring that the association between IoT devices and BIM components is not affected.

[0047] Furthermore, the unified identifier system provides fundamental support for subsequent one-to-one, one-to-many, many-to-one, and composite mapping relationships, enabling data from different sources to be parsed and matched within the same identifier space, reducing system coupling complexity. During long-term operation and maintenance, this mechanism can adapt to changing scenarios such as equipment replacement, model reconstruction, and professional adjustments, maintaining the continuity and consistency of data associations, thereby improving the overall system's maintainability and scalability.

[0048] In the process of associating IoT data with BIM models, there are often differences in identification systems and semantic levels between different data sources. Therefore, it is necessary to construct various types of mapping relationships to adapt to the complex association needs in actual engineering. Based on the definitions in the briefing materials, mapping relationships can be divided into four basic types: one-to-one, one-to-many, many-to-one, and composite mapping. These four types of relationships together constitute a complete data association framework.

[0049] A one-to-one relationship means that one IoT device corresponds to one BIM component. This relationship structure is the simplest and is suitable for scenarios where there is a clear physical correspondence between devices and components. For example, the vibration sensor of a single water pump only serves that water pump component, and its measurement data directly reflects the operating status of that component. Under this relationship, the data flow path is clear, and the mapping process does not require additional splitting or aggregation processing, making it suitable for basic monitoring equipment.

[0050] A one-to-many relationship indicates that one piece of equipment corresponds to multiple BIM components. This situation typically occurs when the equipment's influence covers multiple structural units. For example, the vibration generated by a water pump may simultaneously act on multiple related components such as the inlet valve, outlet valve, base, and motor. In this case, a single data source needs to propagate to multiple target objects, and its mapping results need to undergo fan-out processing to copy the data from the same measurement point and apply it to multiple components, thereby achieving synchronous updates for multiple targets.

[0051] A many-to-one relationship indicates that multiple measurement points correspond to the same BIM component. This relationship is common in multi-sensor fusion scenarios. For example, multiple measurement points such as temperature, humidity, and smoke are deployed inside a cabinet. These measurement points reflect the state of the same component from different dimensions. In this structure, data from different measurement points may arrive simultaneously and cause conflicts. Therefore, it is necessary to filter the data in subsequent processing by combining priority or time order to determine the valid data source that ultimately drives the state of the component.

[0052] Composite mapping relationships further expand data fusion capabilities, representing the synthesis of driving signals for one or more components through function operations. For example, temperature and humidity data and personnel density information within a room can be combined using a function to generate a comfort index, which can then be used to drive the state expression of related components or spatial units. This relationship not only involves data association but also includes certain data processing logic, enabling the system to express higher-level semantic information.

[0053] The four types of mapping relationships described above cover different levels of needs, from simple direct associations to complex data fusion, enabling IoT data to be flexibly distributed and uniformly managed in a multi-source, multi-objective environment. By incorporating these relationships into a unified mapping system, the coupling complexity between different data sources can be effectively reduced, and a clear data flow path can be provided for subsequent differential calculations and rendering updates. Simultaneously, this structure possesses good scalability, adapting to actual operational scenarios such as increases in device types, changes in the number of measurement points, and adjustments to business logic, ensuring the stability and consistency of the system during long-term operation.

[0054] During the operation of IoT data-driven BIM models, after data is parsed through composite mapping relationships, multiple candidate targets or multiple data sources may simultaneously act on the same target, leading to conflict issues. To ensure the determinism and consistency of the system output, a clear conflict resolution mechanism needs to be established, enabling data from different sources to be processed according to unified rules within the same rendering cycle, thereby avoiding chaotic or unstable state representation.

[0055] A conflict is determined when IoT data, after being queried through a composite mapping, yields two or more candidate targets, or when multiple IoT data points point to the same target within the same rendering cycle. To address this issue, three types of rules are used, each corresponding to a different type of mapping relationship, thus ensuring consistency between the processing logic and the mapping structure.

[0056] The first type is the priority rule, corresponding to a many-to-one relationship, where multiple measuring points act on the same component. In this case, if priorities have been set for each measuring point in the mapping configuration, such as smoke sensor > temperature sensor > humidity sensor, then the selection is based on priority, using only the value of the highest priority measuring point as the valid driving data for the current cycle. The data from the remaining measuring points will not participate in the current rendering calculation; they are only recorded in the state cache for possible subsequent updates. This mechanism can prevent low-priority measuring points from frequently overwriting high-priority alarm information, thereby ensuring the stability of critical state representation.

[0057] The second type is the Last-Writer-Wins rule, applicable to many-to-one relationships without configured priorities. When multiple measurement points simultaneously point to the same component and no priority is defined, the decision is made based on time order. Specifically, data with a larger timestamp overwrites data with a smaller timestamp; when timestamps are the same, the later-arriving data takes precedence, ensuring that the final state always reflects the latest data. This rule can be formally expressed as: in: This indicates the value ultimately used to drive the component's state; This represents the IoT data value with the largest timestamp. This represents the maximum timestamp in the current candidate dataset.

[0058] This rule ensures that the system output is consistent and predictable under conditions without priority constraints.

[0059] The third type is the fan-out rule, corresponding to a one-to-many relationship, where a single measuring point is mapped to multiple components. In this case, the state change of a measuring point needs to simultaneously affect multiple target objects. Therefore, the measuring point data needs to be copied into multiple independent difference terms and applied to each target component respectively. This process can be represented as: in: Indicates that for the first The difference terms generated by each target component; Indicates the first The identifier of each target component; Indicates the state value of the source measurement point; Indicates the corresponding timestamp; This indicates the number of target components in the mapping relationship.

[0060] This mechanism enables synchronous driving of multiple target objects from a single source of data, while ensuring that each target has an independent data channel in the rendering process.

[0061] The three types of rules mentioned above correspond to many-to-one, one-to-many, and undefined priority special cases, respectively. Their judgment logic corresponds one-to-one with the mapping relationship type, ensuring that conflict handling has clear boundaries and execution order. Under the same input data and the same mapping configuration, the processing results remain consistent, thus exhibiting good reproducibility.

[0062] By introducing priority filtering, time-order decision-making, and data fan-out mechanisms, conflicts arising from concurrent input of multi-source data can be effectively resolved, avoiding chaotic state overwriting or inconsistent representation. Simultaneously, this mechanism works in conjunction with front-end state caching and differential update processes, ensuring unified data processing before rendering, thereby improving the overall system stability and responsiveness.

[0063] During the operational phase, state difference generation plays a crucial role in reducing invalid updates and improving system response efficiency. Its processing logic revolves around the principle of processing only changed data. Upon receiving an IoT data packet, the client typically finds information such as device identifier, measurement point identifier, current value, and timestamp. First, the target set is located through a composite mapping relationship. If the target set is empty, it means that the measurement point has not been associated with any rendering object. Such data will be discarded directly to avoid meaningless data from entering the subsequent processing flow.

[0064] When the target set When the data is not empty, each target object in the set needs to be processed individually. The system reads the current state value of the target from the state cache and compares it with the newly received data. If they are equal, it means that the data has not caused a state change, and it is judged as an invalid update and discarded directly, fundamentally suppressing the performance overhead caused by high-frequency repeated reporting. If there is a difference, the change content needs to be further calculated, and the change is classified into different categories according to the type of the target object, including style, transform, animation, and visibility. Each valid change is encapsulated as a difference item and records information such as target identifier, change type, change value, timestamp, and version number.

[0065] In the difference generation process, the processing logic can be abstracted into the following form: in: It is the first One difference term; It is a unique identifier for the target object; It is the change type, with values ​​of style, transform, anim, or visibility; This is the changed status value; It is a timestamp, used to record when the data was generated; It is the version number, used to identify the order of the difference items.

[0066] After processing a single data packet, all difference items generated in the current rendering cycle are aggregated and encapsulated into a difference packet. The difference packet contains not only the difference item set but also unified header information describing the overall attributes of the batch of data. Its structure can be represented as follows: in: It is the overall structure of the differential package; It is a monotonically increasing version number used to identify the current sequence position of the difference packet; It is the differential packet timestamp, indicating the generation time of this batch of data; It is a data source identifier, such as a gateway node; It is the set of all difference terms within the current period.

[0067] The differential packet, as the output of the state differential generation stage, constitutes the sole data input interface for subsequent processing stages. Upon entering the next processing stage, the system operates solely based on the differential packet, no longer directly accessing the original IoT data or model geometry information, thus decoupling the data flow and simplifying the processing path. All differential packets are pushed into the rendering queue, awaiting distribution and processing according to the change type.

[0068] From a computational complexity perspective, the difference generation process relies on a hash structure to implement state caching and mapping lookup; therefore, the processing time for a single IoT data packet is constant. When a measurement point is mapped to... When dealing with one target object, the overall processing complexity is O(n). .in, This parameter represents the number of elements in the target set and directly affects the number of difference terms generated.

[0069] The above mechanism ensures that only truly changed data is processed and transmitted, avoiding unnecessary updates that consume computing and rendering resources. Simultaneously, the unified encapsulation of differential packets provides a clear data interface for subsequent rule distribution and rendering execution, enabling the system to maintain stable and efficient operation even under high-frequency data input environments.

[0070] During runtime, the organization and execution of rendering instructions rely on the synergy between the rule engine and the layered rendering mechanism. After generation, the differential packets first enter the rule engine for classification. The rule engine uses the change type in the differential items as the core routing basis, distributing different types of data to the corresponding processing channels. Specifically: When the change type in the difference item is style, the corresponding visual attributes such as color, transparency, stroke and label are processed. When the type is transformation, the corresponding position, rotation, and scaling matrices are updated; When the type is animation, it corresponds to animation clips, motion speed, and trajectory control; When the type is visibility, it controls the display status or blinking effect of the object.

[0071] Each processing logic exists as an independent processor and is managed through unified configuration.

[0072] Rule configurations are expressed in structured JSON format, enabling configurability of different types of mapping relationships and processing logic. During runtime, the business side can dynamically adjust rules and apply them instantly without interrupting the rendering process, thereby improving the system's flexibility and maintainability in complex application scenarios. The rule engine's input is a differential packet structure, in the following form: in: It is a monotonically increasing version number used to identify the order of differential packets; It is a timestamp, indicating when this batch of data was generated; It is a data source identifier, such as a gateway node; It is a set of difference terms.

[0073] The structure of each difference term is as follows: in: It is the first One difference term; It is the identifier of the target object; It is a change type; It is a changed value; : timestamp; Version number.

[0074] After the rules engine completes the routing, the differential data enters the front-end layered rendering execution stage. The client processor first identifies the type of the target object in the differential item through the mapping relationship, classifying the object into two categories: static components and dynamic entities.

[0075] For static components, the update path directly operates on the attribute buffer in the graphics processing unit's video memory, modifying it through the `color` or `show` interface of `Cesium3DTileFeature`, or the `Mesh.material` related property handles in `three.js`. This type of update only changes rendering properties and does not involve geometric reconstruction, thus significantly reducing CPU involvement.

[0076] For dynamic entities, the update path is implemented through an independent object control interface, including the position, quaternion, and scale properties of Object3D, or by driving the animation state through an animation mixer. This approach enables dynamic objects to have independent spatial transformation capabilities, allowing them to respond to IoT data and perform continuous or discrete motion behaviors.

[0077] During rendering, only objects affected by the differential are marked and their state is set to dirty. In the next frame, only the pixel regions corresponding to the marked objects are redrawn, while unaffected static parts remain cached in video memory. This mechanism effectively reduces the GPU's computational burden and improves overall rendering efficiency.

[0078] Furthermore, the component undergoes multiple state transitions during operation, and its state machine can be described as the switching relationship between multiple discrete states: Initial stage: in placeholder state; Loading complete: Entering virtual state; Data access: Entering running state (Active); Anomaly detection: Switch to alarm state; return to running state after the alarm is cleared. Device offline: Enters offline state; returns to running state after reconnection. Maintenance process: Enters maintenance mode, and returns to running mode after completion.

[0079] This state transition process can be abstracted as a set of states: in: This is a placeholder state before the model is loaded; It is a virtual state where the model has been loaded but real-time data has not been connected; It is in normal operating condition; It is an alarm triggered state; The device is offline. It is under maintenance.

[0080] The transitions between states are driven by IoT data events, such as device arrival, alarm triggering, alarm clearing, IoT offline, and IoT recovery. This state machine structure ensures that the rendered representation is consistent with the business state, avoiding inconsistencies between different modules.

[0081] Through the collaboration of the rule engine and the layered rendering execution mechanism, efficient mapping from differential data to graphical representation can be achieved, ensuring that the system still has stable responsiveness and consistent visual output effects in high-frequency data input environments.

[0082] In the process of multi-source IoT data-driven 3D rendering, the time-series coordination of multiple processing stages is involved from data generation to the completion of image updates by the graphics processing unit. This time-series link starts from the IoT device side, and forms a complete data-driven path through communication transmission, edge preprocessing, front-end computing and GPU execution, with strict sequence and functional division between each stage.

[0083] After generating raw data, IoT devices send data packets to the edge gateway via MQTT or WebSocket protocols. These data packets contain information such as device identifier, measurement point identifier, data value, and timestamp. Upon receiving the data, the edge gateway performs preprocessing operations, including deduplication and frequency limiting, to reduce the pressure on backend processing caused by high-frequency repetitive data. The processed data is then encapsulated into standard data packets and pushed to the front-end processor.

[0084] After receiving data, the front-end processor first performs a composite mapping lookup to locate the target set through the mapping relationship. This set represents one or more rendering objects that the current data packet may affect. Then, it enters the state difference generation stage, reading the current state of the target objects through the state cache and comparing it with the new data. If they match, it is determined that there is no change, and such data will not proceed to the next step; if there is a difference, a difference term is generated. The structure of the difference term can be represented as: in: It is the first One difference term; It is the identifier of the target object; It refers to the type of change, including style, transformation, animation, or visibility; This is the changed status value; It's a timestamp; It is a version number used to indicate the data order.

[0085] All difference items generated within a rendering cycle are aggregated and packaged into a difference package, the structure of which is as follows: in: It is the differential package version number, which increments in chronological order. This refers to the differential packet generation time; It is a data source identifier; It is a set of difference terms.

[0086] When the difference packet is empty, meaning no valid changes have occurred, the data is silently discarded on the front end, and no further rendering updates are triggered, thus preventing invalid data from consuming GPU resources. When the difference packet is not empty, the rule distribution phase begins, where routing is performed based on the change type in the difference item, and the data is ultimately passed to the rendering execution path.

[0087] During the rendering execution phase, differential data is applied directly to the attribute buffer in the graphics processing unit's video memory via object handles. Upon receiving an update instruction, the GPU redraws only the affected areas in the next frame and confirms the update for the current frame through a feedback mechanism. Throughout this process, unchanged objects remain cached in video memory, thus reducing rendering overhead.

[0088] In addition to the real-time processing path, there is an independent consistency maintenance path. The front-end processor performs version checks periodically, determining whether there is missing data by detecting the continuity of differential packet version numbers. When a version jump is detected, a packet replacement mechanism is triggered; if the packet replacement request does not receive a response within a set time, a complete snapshot of the current state is requested from the server to restore state consistency. This snapshot only contains state information and does not involve model geometry data, thereby reducing transmission overhead.

[0089] The consistency maintenance process also relies on the version number parameter, and its determination logic can be expressed as follows: in: It is the version number of the currently received differential packets; It is the highest version number that has been recorded.

[0090] The above mechanism can maintain eventual data consistency even when there is network jitter, packet loss, or out-of-order delivery.

[0091] The entire time-series process exhibits two key characteristics: First, high-frequency but unchanging data is filtered step-by-step at the edge gateway and front-end processing stages, with only valid changes entering the rendering path; second, the consistency maintenance mechanism operates independently of the real-time rendering channel and does not block the real-time update process. This dual-channel structure ensures reliable synchronization of system states while guaranteeing rendering real-time performance, enabling data-driven rendering to maintain stable operation even in complex network environments.

[0092] In data-driven rendering, to ensure state consistency in complex network environments, a dual-track maintenance mechanism based on version numbers and state snapshots is required. Each differential packet carries a monotonically increasing version number during generation. The front end maintains the currently known maximum version number for each device identifier. This serves as the core basis for judging the validity and completeness of the data.

[0093] When a new differential packet arrives, its version number is compared first. If the following relationship is satisfied: This indicates that the current difference packet contains duplicate or out-of-order data. Such data will no longer participate in the state update process and will be discarded directly, thereby preventing old data from overwriting the new state and ensuring that the system always uses the latest state as the standard.

[0094] When the following conditions are detected: This indicates a version gap, meaning some differential data was not successfully received. In this case, the system will trigger a packet retransmission request for the missing section, with the edge gateway or server attempting to resend the missing differential data. The retransmission request waits for a set timeout period; if no valid response is received within this timeframe, the differential link is considered unable to restore complete continuity.

[0095] In the event of a packet replacement failure, a full snapshot alignment mechanism is initiated. The frontend requests a complete state snapshot of the current device from the server to rebuild the local state cache. This state snapshot only contains the current state value and time information, excluding model geometry data, thus reducing network transmission burden while ensuring data consistency. After the snapshot is loaded, the local cache is updated, and the maximum version number is updated accordingly. It has been reset to the version base corresponding to the current snapshot.

[0096] During continuous operation, a sliding window mechanism is used to statistically analyze the reception of differential data. When the cumulative loss rate exceeds a preset threshold within a certain time window, it indicates that the current network environment is unsuitable for continuing to rely on differential data for updates. At this point, the system automatically switches to full polling mode. In this mode, complete status data is periodically requested from the server to ensure the reliability of status updates. Once the network quality recovers to a stable level, the system automatically switches back to differential update mode, thus balancing performance and stability.

[0097] The key parameters involved in the above mechanism include: It is the version number of the currently received differential packets, which monotonically increases in chronological order; It is the highest version number currently recorded, used to determine whether new data is valid; version interval. Used to detect missing data; Packet replacement timeout: used to control the waiting period for packet replacement requests; Sliding window length: used for the time range of statistics on the loss rate; Loss rate threshold: used to determine whether to switch update modes; Polling period: the time interval for requesting data in full mode.

[0098] Through the aforementioned version control and snapshot compensation mechanisms, eventual consistency of state updates can be maintained even under complex conditions such as out-of-order data, duplication, or loss. Simultaneously, separating the consistency maintenance process from the real-time rendering path ensures that rendering updates are triggered only when valid changes occur, thereby avoiding unnecessary performance overhead. This mechanism effectively balances real-time performance and stability in high-frequency IoT data stream environments, ensuring reliable system operation under various network conditions.

[0099] During project implementation, the implementation paths differ across different rendering engine environments. Therefore, it is necessary to design corresponding execution methods for specific technology stacks to ensure that the differential data-driven mechanism can run stably in the actual system. Based on the principle of layered processing of static components and dynamic entities, multiple implementation methods can be formed to adapt to different 3D engine architectures and model data forms.

[0100] In a CesiumJS-based implementation environment, static layers are loaded via Cesium3DTileset, and static components reside in the graphics processing unit's video memory as 3DTiles slices. State changes of static components are controlled through the attribute interfaces provided by Cesium3DTileFeature, including color, show, silhouette, and label, to achieve effects such as color changes, visibility toggles, outline strokes, and label display. This approach directly operates on the attribute buffer in video memory, eliminating the need to reconstruct geometric data and ensuring rendering efficiency. Dynamic entities are managed using Entity or Primitive objects, with their spatial state controlled by transformation matrices or orientation parameters. The core update method can be abstracted as follows: in: It is a comprehensive transformation description of dynamic entities; A matrix used to describe position and scaling; Used to describe rotational state; Used to control animation behavior.

[0101] In the three.js environment, static models are typically rendered by loading glTF format files via GLTFLoader or by rendering glTF data converted from 3DTiles. Updates to the state of static components primarily rely on modifications to material properties, such as color changes via Mesh.material or MeshStandardMaterial.color, thus updating the style layer. Dynamic entities are controlled through Object3D objects and animated using AnimationMixer. Their update process can also be summarized as a unified transformation expression: in: It is a spatial position vector; It is a rotation representation in quaternion form; It is a scaling parameter; These are animation control parameters.

[0102] This approach maintains a consistent logical structure with the CesiumJS path, where static objects only update properties, while dynamic objects update transformations or animations, thus achieving a unified layered control strategy.

[0103] In scenarios where component-level featureIds cannot be preserved, such as when the model loses its original identifier information after complex merging or compression, alternative solutions are needed to maintain object-level control. In such cases, an external spatial index structure can be built during the preprocessing stage, such as a bounding box set or a spatial partitioning structure based on octree. Each spatial node is associated with a business identifier, thus forming a proxy object system. During runtime, the target region is quickly located through the spatial index, and the proxy object takes over the style or state expression, achieving indirect control over the original component. This process can be abstractly represented as: in: It is a proxy object; It refers to the bounding box space range corresponding to the component; It is a business identifier; This is the current status information.

[0104] The three implementation paths described above can cover the application requirements of mainstream 3D engines and different model data conditions. Regardless of the method used, the core idea remains consistent: using differential data to drive attribute updates and transformation control avoids redundant calculations of geometric structures, thereby reducing system load. Simultaneously, a unified identification system and mapping relationships ensure that IoT data can accurately locate target objects in different engine environments, achieving consistent behavior across platforms. This design gives the system good scalability and engineering adaptability, enabling stable operation in various practical deployment environments.

[0105] This invention avoids the problem of full traversal of the front-end scene graph in traditional solutions by introducing a static and dynamic classification mechanism based on dynamic scoring and a unified identifier mapping system in the IoT data-driven process. Upon arrival of IoT data, the target object can be quickly located directly through the mapping index, and the corresponding update path can be entered according to the object type, achieving constant-time data location and processing. This approach significantly reduces the computational overhead of a single state update, enabling the system to maintain millisecond-level response capabilities even under high-frequency data input conditions, thus improving overall real-time performance.

[0106] This invention employs a rendering strategy combining differential driving and dirty region updates. It only marks and triggers local redraws for objects that have changed, while maintaining the static layer memory cache unchanged. By reducing unnecessary global refresh operations, it effectively lowers the GPU computational burden, making the rendering process unaffected by high-frequency data fluctuations in IoT, thus stably maintaining a high frame rate output. This mechanism can consistently guarantee a smooth visual experience under complex scenes and large-scale model conditions.

[0107] This invention achieves unified management of IoT device identifiers, BIM component identifiers, and rendering layer identifiers through a decoupled design of identifier standardization and composite mapping, and persistently stores the mapping relationships. During long-term operation and maintenance processes such as model tile reconstruction, device replacement, or professional segmentation, this mechanism ensures the stability of the identifier system, preventing the loss of association relationships due to changes in model structure, thereby improving the system's maintainability and scalability.

[0108] This invention achieves precise control over position, pose, and animation by separating objects requiring pose changes from static slices into independent dynamic entities and combining this with an update method that directly operates on the object handle. Simultaneously, a dirty area redrawing strategy reduces the involvement of irrelevant objects in calculations, resulting in more stable performance of dynamic devices during operation, significantly reducing frame drops and stuttering, and improving the reliability of dynamic performance.

[0109] This invention is compatible with mainstream 3D rendering engine environments at the implementation level, providing corresponding interface implementation paths under the CesiumJS and three.js frameworks, covering key capabilities such as static property updates and dynamic transformation control. This design does not rely on any commercial closed-source platform, possesses excellent engineering feasibility and cross-platform adaptability, and can be quickly deployed and run stably in various practical application scenarios.

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

Claims

1. A method for incremental update of BIM model driven by IoT based on component-level differential coding, characterized in that, Includes the following steps: The components in the BIM model are weighted based on component type, business tag, frequency of change of associated IoT measurement points and geometric independence to obtain dynamic scores, and are divided into static component sets and dynamic entity sets according to thresholds. The static component sets are published as 3DTiles static tiles, and the dynamic entity sets are published as independent glb or gltf files. Generate unified identifiers for static component sets and dynamic entity sets, and establish mapping relationships between IoT device identifiers, measurement point identifiers, BIM component identifiers, 3DTiles feature identifiers, and dynamic entity identifiers; The target set is located based on the mapping relationship. The value of the IoT data packet is compared with the current state of the corresponding target. When there is a difference, a differential data packet containing the target identifier, change type, change value and version number is generated. The object type is determined according to the target identifier in the differential data packet. The display attributes in the graphics processing unit's video memory are updated for static components, and the transformation parameters or animation status are updated for dynamic entities. Version control is implemented for differential data packets. When out-of-order or missing packets occur, they are discarded or compensated. If compensation fails, a snapshot of the current state of the target is obtained to update the cache. When the loss rate exceeds the threshold, the system switches to periodic polling mode.

2. The IoT-driven incremental update method for BIM models based on component-level differential coding according to claim 1, characterized in that, The dynamic score is calculated using the following weighted expression: In this formula, the parameters have the following meanings: This represents the BIM component object to be evaluated; Representation of components The dynamic score is used to measure whether it is suitable to be classified as a dynamic entity; The weighting coefficients corresponding to the four types of evidence satisfy the following constraints: The weight values ​​range from 0 to 1 and are used to adjust the degree of influence of different pieces of evidence on the final score. The four types of decision functions are all indicators, taking values ​​of 0 or 1, used to indicate whether the corresponding condition is true or false. The specific definitions of the four types of decision functions are as follows: Type of evidence: in, The BIM type identifier for the component. This represents a predefined set of active types, such as IfcDoor, IfcValve, IfcActuator, and IfcDamper. Business evidence: Among them, the business tag is used to describe the functional role of the component in the actual project. This evidence is used to make up for the problem that relying solely on the Ifc type cannot accurately express business behavior. Behavioral evidence: in, This indicates the frequency of change in IoT measurement point data associated with the component. The frequency threshold is used to determine whether the changes at the measuring points have reached a level of frequent change; this evidence reflects whether the component has a continuous dynamic update requirement during operation. Geometric evidence: This criterion is used to evaluate whether a component has the ability to be independently extracted from the slice model at the geometric level, and it is particularly critical for components that have been merged or baked into the overall mesh; After completing the scoring calculation, the classification is based on the following judgment rules: in: It is a dynamic threshold used to control the classification boundary; This is the component classification result, with values ​​of dynamic or static. Dynamic means that the component is stripped into an independent GLB or GLTF dynamic entity, which can be controlled in position, pose and animation at runtime. Static means that the component is retained in the 3DTiles static slice, only participating in the overall rendering, and does not undergo independent pose updates.

3. The IoT-driven incremental update method for BIM models based on component-level differential coding according to claim 1, characterized in that, During the parsing process, the composite mapping handles conflicts according to the following rules: when multiple measurement points are mapped to the same component, the data source with the highest priority is selected according to the preset priority; when a measurement point is mapped to multiple components, fan-out is performed in a one-to-many manner; when no priority is configured, the Last-Writer-Wins rule is adopted, and the one with the larger timestamp overwrites the one with the smaller timestamp.

4. The IoT-driven incremental update method for BIM models based on component-level differential coding according to claim 1, characterized in that, During the version-snapshot consistency maintenance process, each differential data packet carries a monotonically increasing version number. The front-end processor maintains a known maximum version number for each target. When a new version number is less than or equal to the maximum version number, it is judged as a duplicate or out of order and discarded. When the version number is greater than the maximum version number plus one, it is judged as missing and a timed packet replacement request is triggered. When the packet replacement request times out and does not respond, the complete state snapshot of the corresponding target is obtained from the server to overwrite the local cache.

5. The IoT-driven incremental update method for BIM models based on component-level differential coding according to claim 4, characterized in that, The complete state snapshot only contains the current state value and timestamp information, but does not contain model geometry data. When the cumulative loss rate of differential data packets exceeds a preset threshold within the sliding window, it switches to the periodic full polling mode and automatically switches back to the differential update mode after returning to normal.

6. The IoT-driven incremental update method for BIM models based on component-level differential coding according to claim 1, characterized in that, During the layered execution of rendering instructions, dynamic entities are constructed using the instantiation rendering method of the graphics processing unit. Multiple dynamic entities of the same type share the same geometric data, store their own instance attribute buffers only in video memory, and only mark the affected instances as dirty data. In the next frame, only the corresponding pixel area is redrawn.

7. The IoT-driven incremental update method for BIM models based on component-level differential coding according to claim 1, characterized in that, Static components are updated in state through the attribute buffer in the graphics processing unit's video memory. During state changes, the video memory cache of the static slice model remains unchanged to avoid repeated loading or reconstruction of the model's geometric data.

Images