Digital twin system based on modular component architecture and visual assembly method

Abstract

The present application relates to the technical field of three-dimensional visualization simulation, and specifically discloses a digital twin system based on a modular component architecture and a visualization assembly method, wherein the present application encapsulates geometric models, attribute parameters and business logic into standardized modular components, completes component dragging assembly and graphical logic rule configuration in a visualization editor, constructs a component assembly template and generates a digital twin through runtime instantiation, builds a multi-mode mapping event-driven bidirectional data synchronization mechanism, realizes state linkage between the twin and external heterogeneous data sources, and solves the spatiotemporal inversion pose in combination with a pre-rendering compensation mechanism, aiming at the network delay problem of geographical scene motion entities, by using a multi-objective optimization objective function combined with road network hard constraints. The present application can improve component reuse capability, reduce modeling threshold, realize multi-source data bidirectional linkage, effectively suppress motion entity visualization trajectory jump jitter, and adapt to various business scenarios in industry and geographical transportation.

Description

Technical Field

[0001] This invention relates to the field of three-dimensional visualization and simulation technology, and in particular to a digital twin system and visualization assembly method based on a modular component architecture. Background Technology

[0002] Digital twin technology, by constructing virtual models that map to physical entities, enables the visual reproduction, real-time simulation, and business logic-driven operation of physical object states. It is now widely used in scenarios such as industrial equipment monitoring, traffic network simulation, and geospatial situation simulation. Currently, digital twin platforms mostly adopt a monolithic model development model, which strongly couples the model with business logic. Model components, attribute configurations, and business rules are deeply bound, making it difficult to achieve component reuse and visual drag-and-drop assembly.

[0003] In existing digital twin modeling solutions, 3D models, business attributes, and logical decision-making code are typically hard-coded into the program by developers. When it is necessary to build twins of different specifications and with different business logic, the code must be rewritten and a custom model must be developed, resulting in a long modeling cycle and poor versatility. Although some platforms have introduced a simple component-based approach, they only support drag-and-drop layout of basic geometric components and lack the corresponding graphical logic rule configuration capabilities. They cannot directly complete multi-condition combination judgments and condition-action linkage configurations within a visual editor. Business logic still relies on secondary development of backend code, making it difficult for non-professional developers to independently complete the business definition of the twin.

[0004] On the other hand, most existing digital twin data synchronization mechanisms adopt a one-way data forwarding mode, which can only push external IoT data to the twin model in one direction. They lack the ability to flexibly map multi-source heterogeneous data, making it difficult to achieve reverse event notification from the twin's state to the external system. Furthermore, in geographic simulation scenarios of moving entities, network transmission delays cause lag in physical entity pose data. Traditional solutions directly update the 3D scene using received historical data packets, which easily leads to problems such as model position jumps and trajectory distortion. Conventional motion constraints only limit velocity and acceleration boundaries, without considering the motion smoothness constraints caused by abrupt changes. In scenarios with network latency, the virtual motion trajectory calculated exhibits significant jitter, failing to meet the visualization requirements for high-precision spatiotemporal synchronization of moving entities in geographic scenarios.

[0005] Therefore, there is an urgent need for a digital twin system and a visual assembly method based on a modular component architecture to solve the above problems. Summary of the Invention

[0006] The purpose of this invention is to provide a visual assembly method for digital twins based on a modular component architecture, comprising the following steps: Obtain the physical entity object metadata and functional component configuration metadata of the digital twin to be assembled; Based on the physical entity object metadata, obtain unified component interface data, and based on the unified component interface data, obtain the set of assembleable components and component metadata; Component attribute data and logical rule data are obtained based on the configuration metadata of the functional components, and the component attribute data and logical rule data are associated and merged with the set of assembleable components to obtain a modular component data chain; Visual assembly data is obtained based on the modular component data chain, and a twin data model to be instantiated is obtained based on the visual assembly data. When the twin data model to be instantiated is not within the preset component assembly template, the twin data model to be instantiated is matched with the preset component assembly template to obtain a similar assembly template, and the similar assembly template is supplemented with component semantics based on the visualized assembly data to obtain a newly defined component assembly template. The target digital twin is obtained by runtime instantiation and visual assembly of the digital twin to be assembled according to the newly defined component assembly template.

[0007] Furthermore, the present invention also discloses a digital twin system based on a modular component architecture, comprising: The first acquisition module is used to acquire the physical entity object metadata and functional component configuration metadata of the digital twin to be assembled; The second acquisition module is used to acquire unified component interface data based on the physical entity object metadata, and acquire a set of assembleable components and component metadata based on the unified component interface data. The merging module is used to obtain component attribute data and logical rule data according to the configuration metadata of the functional components, and to associate and merge the component attribute data and the logical rule data with the set of assembleable components to obtain a modular component data chain. The model acquisition module is used to acquire visual assembly data based on the modular component data chain, and to acquire the twin data model to be instantiated based on the visual assembly data. The assembly module is used to perform similarity matching between the twin data model to be instantiated and the preset component assembly template when the twin data model to be instantiated is not in the preset component assembly template, to obtain a similar assembly template, and to supplement the similar assembly template with component semantics based on the visualized assembly data to obtain a newly defined component assembly template. The processing module is used to instantiate and visually assemble the digital twin to be assembled at runtime according to the newly defined component assembly template, so as to obtain the target digital twin.

[0008] The beneficial effects of this application are as follows: Firstly, this invention constructs a modular component system that can be registered and dragged and assembled. Geometric models, attribute parameters, and business logic are encapsulated into standardized components, supporting the assembly of digital twins at the hierarchical level within a visual editor. This allows for rapid construction of digital twins without writing underlying code, improving component reusability, shortening the development cycle of digital twin models, and lowering the threshold for business modeling. Furthermore, the graphical logic rule configuration module supports multi-condition combination operations, interval mapping, action chain timing, and exception handling. It allows for the direct visual definition of digital twin business logic, eliminating reliance on backend code development and enabling flexible configuration of business rules.

[0009] Secondly, this invention supports one-to-one, one-to-many, and many-to-one heterogeneous data mapping by building a multi-mode attribute mapping and event-driven bidirectional data synchronization architecture. External data sources and twins can trigger state updates bidirectionally, taking into account both incremental updates and batch synchronization, reducing system transmission overhead while ensuring data real-time performance.

[0010] Thirdly, this invention addresses the pose lag problem caused by network transmission delays in moving entities within a geographic scene. It introduces a spatiotemporal inversion synchronization mechanism based on road network constraints, adding jerkiness as a motion smoothing constraint in addition to velocity and acceleration. A multi-objective optimization function is constructed, fusing jerkiness minimization, path lateral deviation, and terminal velocity matching terms. This reduces the 3D pose solution to a single-degree-of-freedom optimization problem along the road network arc length, improving pose solution efficiency and trajectory matching accuracy. Simultaneously, the next frame's motion command is pre-generated based on the solution residuals, and pre-rendering compensation is performed during packet loss or delay periods, effectively suppressing model position jumps and trajectory jitter in 3D visualization scenes, achieving high-precision, smooth spatiotemporal synchronization between physical entities and digital twins.

[0011] Fourth, the complete method system proposed in this invention can be adapted to various scenarios such as industrial equipment and geographical transportation, taking into account the convenience of modeling, the flexibility of business configuration and the visualization effect of real-time simulation. It can effectively make up for the shortcomings of traditional single-unit digital twin modeling solutions, such as poor universality and insufficient synchronization accuracy. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of a method flow proposed in an embodiment of this application.

[0013] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0014] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0015] like Figure 1As shown, this application provides a digital twin visualization assembly method based on a modular component architecture, which includes the following steps: S1. Obtain the physical entity object metadata and functional component configuration metadata of the digital twin to be assembled; S2. Obtain unified component interface data based on the physical entity object metadata, and obtain the set of assembleable components and component metadata based on the unified component interface data; S3. Obtain component attribute data and logical rule data according to the configuration metadata of the functional components, and associate and merge the component attribute data and the logical rule data with the set of assembleable components to obtain a modular component data chain; S4. Obtain visual assembly data based on the modular component data chain, and obtain the twin data model to be instantiated based on the visual assembly data; S5. When the twin data model to be instantiated is not within the preset component assembly template, the twin data model to be instantiated is matched with the preset component assembly template to obtain a similar assembly template, and the similar assembly template is supplemented with component semantics based on the visualized assembly data to obtain a newly defined component assembly template. S6. Based on the newly defined component assembly template, instantiate and visually assemble the digital twin to be assembled at runtime to obtain the target digital twin.

[0016] As described in steps S1-S6 above, this invention first obtains the metadata of the physical entity object and the configuration metadata of the functional components corresponding to the digital twin to be assembled. This step is the data source acquisition stage of the entire visual assembly process, which can read the basic description information of the physical entity to be mapped and the component configuration information required by the business functions, providing raw input for subsequent component selection, data association, and template matching. The physical entity object metadata includes the physical entity's device identifier, shape specifications, hardware capabilities, motion parameters, and geographic affiliation information. The functional component configuration metadata records the component types required for the business scenario, the initial values ​​of component parameters, business logic constraints, and dependencies between components. The metadata can be imported from an external IoT platform, parsed from configuration files, or manually entered into the visual interface. By pre-separating the inherent description information of the physical entity and the business function configuration information, the same physical entity object can be adapted to multiple sets of different business function component configurations, avoiding data redundancy.

[0017] The process of obtaining unified component interface data based on the physical entity object's metadata, and then obtaining the set of assemblable components and component metadata based on this unified component interface data, is the core step in modular component screening and capability analysis. It uses the unified component interface as a criterion to filter out all components that can adapt to the current physical entity object, while simultaneously reading the component's own descriptive metadata, providing a basis for the editor's component library display and component instantiation. The unified component interface data defines the interface specifications that components must adhere to; only components that meet these specifications are allowed to be included in the set of assemblable components. Component metadata carries basic information for external display and screening of the component, but does not include the component's internal runtime state. Filtering components through interface constraints ensures the compatibility of subsequent drag-and-drop assembly, instantiation, and cloning operations, preventing incompatible components from being assembled into the digital twin to be assembled.

[0018] Based on the configuration metadata of the functional components, component attribute data and logical rule data are obtained. These data are then associated and merged with the set of assembleable components to obtain a modular component data chain. This step completes the binding of business configuration data with optional components, attaching the required attribute parameters and business logic rules to the corresponding assembleable components, forming a structured and serializable complete digital twin data chain. The modular component data chain is the core carrier of the digital twin data layer, integrating component objects, attribute parameters, logical rules, and hierarchical relationships. It exists independently of the 3D rendering runtime object and can be persistently stored, copied, and transmitted, achieving decoupling between edit-state data and runtime carriers. The association and merging process verifies the matching relationships between components and attributes, and components and logic, filtering out invalid configuration items without corresponding component IDs to ensure data consistency within the modular component data chain.

[0019] The process involves obtaining visual assembly data based on the modular component data chain, and then obtaining a twin data model to be instantiated based on the visual assembly data. This step converts the modular component data chain into assembly description information recognizable by the visual editor and generates an abstract data model that has not yet been loaded into the 3D scene. The visual assembly data includes component selection results, parent-child hierarchy relationships, attribute editing results, and graphical logic configuration results, which support the rendering and previewing of the visual assembly editor subsystem interface. The twin data model to be instantiated is a pure data model and does not have a 3D scene running instance; it can be used for template comparison, reuse, and secondary editing.

[0020] When the data model to be instantiated as a digital twin is not within a preset component assembly template, the data model to be instantiated as a digital twin is matched with the preset component assembly template to obtain a similar assembly template. Based on the visualized assembly data, the similar assembly template is then semantically supplemented to obtain a newly defined component assembly template. This step enables template reuse and template derivation. When no perfectly matching pre-made template exists, a similar assembly template with a similar structure is reused, and then components, attributes, and logic unique to the current business scenario are added to generate a new, reusable assembly template. Similarity matching uses the component type set and component hierarchy as matching factors to calculate the similarity score between the data model to be instantiated as a digital twin and each preset component assembly template. The template with the highest score is selected as the similar assembly template. Component semantic supplementation includes adding missing components, updating component attributes, adding logical rules, and modifying the relationships between components. The generated newly defined component assembly template can be stored in a preset component assembly template library for direct use by other digital twins to be assembled subsequently.

[0021] The newly defined component assembly template is used to instantiate and visually assemble the digital twin to be assembled at runtime, resulting in the target digital twin. This step transforms the template data model into a three-dimensional runtime object, enabling the generation of a complete, renderable, interactive, and responsive target digital twin based on the newly defined component assembly template in the runtime environment. Runtime instantiation differs from editor-prefabricated objects, allowing the twin to be dynamically created during program execution without recompiling project resources; visual assembly fully maps the component hierarchy, attributes, and logic defined in the template to the three-dimensional representation layer object, ultimately outputting a target digital twin with complete components, business logic, and three-dimensional visualization.

[0022] In this embodiment, the steps of obtaining unified component interface data based on the physical entity object metadata, and obtaining the set of assemblable components and component metadata based on the unified component interface data, specifically include: S21. Obtain component interface specification data based on the physical entity object metadata; S22. Obtain unified component interface data according to the component interface specification data, wherein the unified component interface data is used to define a unified component interface, and the unified component interface requires the component to inherit from the scene component and implement the unified component interface. S23. Obtain type-safe conversion data based on the unified component interface data, and perform type-safe conversion between the scene component and the unified component interface based on the type-safe conversion data to obtain component type-safe data; S24. Obtain a component attribute object based on the component type security data, and obtain at least one attribute polymorphic data from the current value, previous value, difference, default value, maximum value, change timestamp, and change interval based on the component attribute object; S25. Obtain component clone data based on the attribute polymorphic data, and obtain component instances based on the component clone data; S26. Obtain component metadata based on the component instance, wherein the component metadata includes at least one of component name, category, icon, description, and production availability flag; S27. Obtain the set of assembleable components based on the component metadata and the unified component interface data.

[0023] As described in steps S21-S27 above, component interface specification data is obtained based on the physical entity object metadata. This step reads the physical entity hardware capability constraints and outputs component interface specification data. The component interface specification data limits the set of interface capabilities that can be adapted to the physical entity. For example, if the physical entity does not support audio output, the corresponding audio component interface capabilities are excluded, which is used to filter components with incompatible hardware capabilities.

[0024] Based on the aforementioned component interface specification data, unified component interface data is obtained. This unified component interface data defines a unified component interface, mandating that all compliant components must simultaneously inherit from the scene component and implement the unified component interface. Inheriting from the scene component ensures that the component possesses the basic capabilities of 3D scene positioning, transformation, and rendering, while implementing the unified component interface ensures that all components provide consistent interfaces for attribute access, cloning, and metadata reading. This dual inheritance-implementation constraint is the foundation for achieving universal component assembly and cloning; components that do not meet this constraint will be directly excluded.

[0025] Type-safe conversion data is obtained from the unified component interface data, and type-safe conversion between scene component objects and unified component interface objects is performed based on the type-safe conversion data, outputting component type-safe data. The type-safe conversion data provides secure object type conversion rules, abandoning forced type casting. During the conversion process, it verifies whether the object truly implements the unified component interface; if the conversion fails, it returns an empty object to avoid memory exceptions caused by illegal object access. The component type-safe data records the conversion verification results and object references.

[0026] Based on the component type security data, a component attribute object is obtained. This object encapsulates all business attributes of the component and maintains polymorphic attribute data. This polymorphic data includes at least one of the following: current value, previous value, difference, default value, maximum / minimum value, change timestamp, and change interval. Specifically, the current value represents the attribute's real-time value, the previous value records the value from the last update, the difference is the current value minus the previous value, the default value is the attribute's initial factory value, the maximum / minimum value includes the maximum and minimum values, the change timestamp records the system time when the attribute was modified, and the change interval records the time difference between two adjacent attribute changes. This polymorphic attribute data can be directly used for attribute change detection, difference analysis, and time-series statistics without requiring redundant calculations from upper-layer business logic.

[0027] Component clone data is obtained based on attribute polymorphic data. The component clone data records all attribute states of the component and is used to completely copy the component object. Component instances are generated based on the component clone data. The component instance is a copy of the component runtime object and has independent attribute storage space.

[0028] The component metadata is read from the component instance. The component metadata includes at least the component name, category, icon, description, and production availability flag. The component name is a readable identifier for the component, the category is used for grouping and displaying components in the editor's component library, the icon is used for the editor's UI display, the description records the component's functionality, and the production availability flag indicates whether the component can be used in a production business environment.

[0029] By combining component metadata and unified component interface data, a set of configurable components is obtained. All components in the configurable component set meet interface constraints and hardware compatibility constraints, carry complete metadata, and can be dragged and dropped to be configured into the digital twin to be configured.

[0030] In this embodiment, the step of associating and merging the component attribute data and the logical rule data with the set of assemblable components to obtain a modular component data chain includes: S31. Obtain the digital twin data layer structure based on the component attribute data, the logical rule data, and the set of assembleable components, wherein the digital twin data layer structure is organized in a tree structure and includes a root node, component nodes, and logical rule nodes. S32. Obtain shared pointer management data according to the digital twin data layer structure, and perform reference counting management on the digital twin data layer structure, component attribute objects, component data objects and logical rule objects according to the shared pointer management data; S33. Obtain dirty flag data according to the digital twin data layer structure, and set the dirty flag to true when adding components, deleting components or changing attributes, and set the dirty flag to false after loading from disk according to the dirty flag data; S34. Obtain serialized data based on the dirty tag data, and perform JSON serialization and deserialization based on the serialized data through the serialization interface and deserialization interface; S35. Obtain the modular component data chain based on the digital twin data layer structure and the serialized data.

[0031] As described in steps S31-S35 above, a digital twin data layer structure is constructed based on component attribute data, logical rule data, and the set of assembleable components. The digital twin data layer structure adopts a tree-like organization, containing a root node, several component nodes, and several logical rule nodes. The root node corresponds to the digital twin body to be assembled. Component nodes attach various assembleable components, and the parent-child relationship between nodes expresses the component hierarchy. Logical rule nodes attach business logic rules and can be associated with one or more component nodes. The tree structure fully expresses the internal object hierarchy of the twin, facilitating traversal and node addition / deletion.

[0032] Based on the digital twin data layer structure, shared pointer management data is obtained. This shared pointer management data defines reference counting rules, and reference counting management is performed on the digital twin data layer structure, component attribute objects, component data objects, and logical rule objects. Each object reference increments the reference count, and each released reference decrements the reference count. When the reference count reaches zero, the corresponding memory object is automatically released. This memory reference counting management method is a conventional technique in the computer field, effectively avoiding dangling pointers and memory leaks, and ensuring memory security in scenarios with frequent additions and deletions of numerous components. This invention only adapts it to the management of various objects in the digital twin data layer without modifying its underlying principles.

[0033] Dirty flag data is obtained based on the data layer structure of the digital twin. The dirty flag data maintains a dirty flag state: when adding or deleting a component, or when a component's attributes change, the dirty flag is set to true; after loading and parsing data from the disk file, the dirty flag is set to false. The dirty flag state identification mechanism is a common technique in data cache management, used to quickly identify whether there are unsaved changes in the modular component data chain. Upper-layer logic can prompt the user to save based on the dirty flags or perform automatic saving. This invention only adapts it to the scenario of data changes in digital twin components.

[0034] Serialized data is obtained based on dirty tag data. The serialized data defines the processing logic for serialization and deserialization interfaces. It supports JSON serialization of the entire digital twin data layer structure to output text, and also supports deserialization from JSON text to reconstruct the complete tree structure. JSON serialization and deserialization are well-known and conventional techniques for computer data persistence and data transmission. This invention only adapts the serialization and parsing of the digital twin data layer tree structure, component attribute polymorphic data, and logical rule configuration data based on the general JSON specification, without requiring any modification to the general serialization principle. The serialized output content includes the tree node hierarchy, component attribute polymorphic data, and all logical rule configurations. Deserialization reconstructs the complete component attribute objects and logical rule objects, restoring the reference relationships.

[0035] By combining the data layer structure of the digital twin with serialized data, a modular component data chain is generated. This modular component data chain maintains a complete tree-like object structure in memory and also has JSON persistence capabilities, allowing it to be saved to disk or transmitted over a network.

[0036] In this embodiment, the step of obtaining visual assembly data based on the modular component data chain includes: S41. Obtain component library registration data according to the modular component data chain, and scan and register components that implement the unified component interface through the automatic registration interface of the visual assembly editor subsystem to obtain the component library. S42. Obtain drag-and-drop assembly data from the component library, and drag the component from the component library to the temporary editing host according to the drag-and-drop assembly data, generate a component instance and assign a unique identifier, parent-child relationship identifier and display order; S43. Obtain attribute editing data based on the component instance, and generate attribute editing interfaces according to a three-level priority, wherein the attribute editor generator registered by the visual assembly editor subsystem has a higher priority than the component-specific editing panel generation interface, and the component-specific editing panel generation interface has a higher priority than the default editing interface automatically generated based on the attribute definition. S44. Obtain logical graphical configuration data based on the attribute editing data; S45. Obtain the visual assembly data based on the logical graphical configuration data.

[0037] As described in steps S41-S45 above, component library registration data is obtained based on the modular component data chain. This data defines the component scanning and registration logic, calls the automatic registration interface of the visual assembly editor subsystem, automatically scans all component types implementing the unified component interface within the program, reads component metadata, completes registration, and generates the component library. The component library groups all registered components by category, providing component preview and search capabilities. The automatic registration interface eliminates the need for manual component registration; newly added components implementing the unified component interface are automatically recognized by the editor.

[0038] The component library retrieves drag-and-drop assembly data, which defines the drag-and-drop interaction logic. Users drag and drop components from the library onto a temporary editing host. This temporary editing host is a container object dedicated to the editing state, and all editing operations are completed within it, without polluting the runtime production scene objects. After dragging and dropping, a corresponding component instance is generated. Each component instance is assigned a globally unique identifier, a parent-child relationship identifier, and a display order. The unique identifier is used to globally locate the component, the parent-child relationship identifier records the component tree hierarchy, and the display order controls the editor UI and the internal drawing order of 3D rendering.

[0039] Attribute editing data is obtained from component instances. This data is used to generate a graphical attribute editing interface, which strictly follows a three-level priority rule. Among them, the first priority is the property editor generator registered by the visual assembly editor subsystem; Second priority: Component-specific editing panel generation interface; The third priority is the default editing interface that is automatically generated based on the component's attribute definition.

[0040] If a valid implementation of a high-priority generation method exists, the high-priority method is used directly, and low-priority methods are not executed. This three-level priority interface generation rule is specifically designed for this invention, differing from the conventional single-mode attribute editing interface generation method, and taking into account the rapid generation of general attributes, component custom panels, and global custom attribute control extensions. The results of editing interface operations are written back to the polymorphic attribute data of the component attribute object.

[0041] Logical graphical configuration data is obtained from the attribute editing data. The logical graphical configuration data records the logical rule editing results completed by the user in the editor's graphical interface, including conditions, actions, combination relationships, and mapping configurations.

[0042] The integrated logical graphical configuration data yields visual assembly data. This visual assembly data integrates component library registration information, the hierarchy and identifiers generated by drag-and-drop assembly, attribute editing results, and graphical logical configuration results, serving as the editor output for generating the twin data model to be instantiated.

[0043] In this embodiment, the logical rule data is graphically configured through a logical rule object, and the specific acquisition steps include: S51. Obtain condition set data and action set data according to the configuration metadata of the functional components, and associate and merge the condition set data and the action set data to obtain condition-action logic data; S52. Obtain multi-condition combination data based on the condition-action logic data, and perform at least one logical operation among AND, OR, and NOT based on the multi-condition combination data; S53. Obtain condition type data based on the multi-condition combination data, wherein the condition type data includes at least one of the following: change condition, equal condition, growth condition, decrease condition, greater than condition, greater than or equal to condition, less than condition, less than or equal to condition, modulo condition, and multiple condition; S54. Obtain action type data based on the condition-action logic data, wherein the action type data includes at least one of modifying component attributes action and calling external interface action; S55. Obtain action chain data based on the action type data, and perform at least one of immediate execution, delayed execution, and exception handling based on the action chain data; S56. Obtain numerical range mapping data based on the condition-action logic data, and define the mapping relationship between attribute value ranges and multiple target values ​​through attribute value range mapping items; S57. Obtain the logical rule data based on the numerical interval mapping data.

[0044] As described in steps S51-S57 above, condition set data and action set data are obtained according to the configuration metadata of the functional components. The condition set data records all business conditions to be judged, and the action set data records all business actions to be executed after the conditions are met. The condition set data and the action set data are associated and merged to obtain condition-action logic data. The condition-action logic data establishes the correspondence between conditions and actions with "condition-triggered actions" as the basic unit. One condition can be associated with one or more actions, and one action can also be triggered by multiple conditions.

[0045] Multi-condition combination data is obtained based on condition-action logic data. This multi-condition combination data defines the rules for combining multiple conditions, supporting at least one of the logical operations: AND, OR, and NOT. The AND operation requires all sub-conditions to be satisfied simultaneously for the combination condition to be considered valid; the OR operation requires any one sub-condition to be satisfied for the combination condition to be considered valid; and the NOT operation negates the result of a single sub-condition. Logical AND, OR, and NOT operations are common and well-known logical operations, belonging to existing conventional technologies. This invention only adapts them to the business condition combination judgment scenario of digital twin components, without improving the operation principle itself. Through multi-condition combination data, complex business judgment logic can be expressed, not just limited to single-condition triggers.

[0046] Condition type data is obtained based on multi-condition combination data. The condition type data defines the specific judgment method for each sub-condition. The condition type data includes at least one of the following: change condition, equal condition, growth condition, decrease condition, greater than condition, greater than or equal to condition, less than condition, less than or equal to condition, modulo condition, and multiple condition. Specifically, the change condition determines whether the attribute value has changed; the equal condition determines whether the attribute value is equal to a specified threshold; the growth condition determines whether the attribute value is trending upwards; the decrease condition determines whether the attribute value is trending downwards; the greater than, greater than or equal to, less than, and less than or equal to conditions determine the size relationship between the attribute value and the threshold, respectively; the modulo condition determines whether the result of taking the remainder of the attribute value with respect to a specified modulus meets the requirements; and the multiple condition determines whether the attribute value is an integer multiple of a specified value. Each condition type corresponds to an independent judgment function, and the condition type data records the condition type identifier and the parameters required for that type. This invention integrates multi-dimensional and comprehensive component attribute judgment condition types to form a dedicated twin component condition judgment system, which differs from existing technologies with single judgment methods and represents a targeted adaptation design of this invention.

[0047] Action type data is obtained based on the condition-action logic data. This data defines the type of action to be executed when a condition is met. Action type data must include at least one of the following: modifying component properties or calling an external interface. Modifying component properties directly changes the value of a target component's property, while calling an external interface sends a request to an external system or triggers an external business process. The action type data records the action category identifier and the parameters required for action execution. For example, modifying component properties requires recording the target component identifier, target property name, and target property value; calling an external interface requires recording the interface address, request parameters, and request method.

[0048] Action chain data is obtained based on action type data. This data organizes multiple actions into an action chain according to their execution order, supporting at least one execution strategy: immediate execution, delayed execution, and exception handling. Immediate execution means the action is executed immediately upon meeting the condition; delayed execution means waiting a specified time after the condition is met before executing the action; exception handling means executing a preset compensation action or logging an error when an action fails. Sequential action execution and exception handling are conventional techniques in program development and are existing technologies. This invention structurally adapts them to the logical action execution chain of the twin component, achieving orderly and stable execution of multiple actions without modifying the basic execution principle. The action chain data ensures that multiple actions are executed sequentially according to a predetermined order, and that the subsequent processing of the entire action chain is not interrupted when a single action fails.

[0049] Numerical interval mapping data is obtained based on condition-action logic data. This data defines the mapping relationship between attribute value intervals and multiple target values ​​through attribute value interval mapping items. Each item includes the lower and upper limits of the attribute value, as well as the target value corresponding to that interval. When an attribute value falls into a certain interval, the target value corresponding to that interval is output. This interval mapping is adapted to the continuous attribute discretization scenario of digital twin components and is the structured mapping rule for determining the business state of the digital twin in this invention. The numerical interval mapping data is used to discretize continuous attribute values ​​into a finite number of target states, such as mapping temperature value intervals to state labels like "normal," "high," and "out of limit," providing a basis for subsequent logical judgments or interface displays.

[0050] Logical rule data is obtained from the numerical interval mapping data. The logical rule data integrates the condition set, action set, multi-condition combination relationship, condition type, action type, action chain, and numerical interval mapping configuration to form a complete and executable business logic rule description, which is stored in the logical rule object for the target digital twin instantiated at runtime to call and execute.

[0051] In this embodiment, the step of instantiating and visually assembling the digital twin to be assembled at runtime according to the newly defined component assembly template to obtain the target digital twin includes: S61. According to the newly defined component assembly template, obtain a data copy of the twin data model to be instantiated through the instance acquisition interface; S62. Obtain a runtime carrier based on the data copy, and instantiate the target digital twin based on the runtime carrier; S63. Obtain component cloning data based on the runtime carrier, and create component instances in batches based on the component template through the component cloning interface; S64. Obtain bidirectional data synchronization data according to the component instance, and perform bidirectional data synchronization between the data layer and the presentation layer through at least one of the data loading interface, data saving interface, cloning interface, deserialization interface and serialization interface; S65. Obtain the target digital twin based on the bidirectional data synchronization data.

[0052] As described in steps S61-S65 above, a data copy of the twin data model to be instantiated is obtained through the instance acquisition interface based on the newly defined component assembly template. The instance acquisition interface reads the twin data model to be instantiated from the newly defined component assembly template and returns a complete data copy of the model. The data copy is independent of the original template, and modifications to the data copy will not affect the newly defined component assembly template itself, thereby ensuring that the template can be repeatedly instantiated and used. Template instance copying is a conventional method of program data processing and belongs to the prior art. This invention only adapts it to the twin template reuse scenario.

[0053] The runtime carrier is obtained from the data copy. The runtime carrier is a container of runtime objects in the 3D scene that carries the target digital twin. It has the ability to perform 3D transformation, rendering, and component mounting. The target digital twin is instantiated based on the runtime carrier, and the basic information of the twin defined in the data copy is written into the runtime carrier to complete the creation of the skeleton of the target digital twin.

[0054] The component clone data is obtained from the runtime carrier. This data records the complete attribute state of each component template in the newly defined component assembly template. Component instances are then created in batches based on these templates via the component cloning interface. The interface sequentially reads each component template, copies its attribute polymorphism data and logical rule relationships, generates independent component instances, and mounts these instances to their corresponding parent-child hierarchical positions under the runtime carrier. The batch creation process is executed from top to bottom according to the component tree hierarchy, ensuring that parent component instances are created before child component instances and that child component instances are correctly mounted to their parent instances. Deep component cloning and batch instantiation are the optimized mechanisms of this invention for modular twin component assembly, solving the problems of low efficiency and hierarchical disorder in traditional single component creation.

[0055] Bidirectional data synchronization is obtained based on component instances. This bidirectional data synchronization defines a data synchronization mechanism between the data layer and the presentation layer, achieving bidirectional synchronization through at least one of the following interfaces: data loading, data saving, cloning, deserialization, and serialization. Specifically, the data loading interface loads the modular component data chain from the data layer into the runtime carrier of the presentation layer; the data saving interface writes back the current state of the presentation layer's runtime carrier to the data layer; the cloning interface copies the object state of either the data layer or the presentation layer; the deserialization interface reconstructs the data layer object from JSON text; and the serialization interface outputs the data layer object as JSON text. While general data read / write, serialization, and cloning interface calls are existing conventional technologies, the improvement of this invention lies in the coordinated adaptation of multiple interfaces to construct a closed-loop bidirectional synchronization system between the twin data layer and the three-dimensional presentation layer. Bidirectional data synchronization ensures consistency between the data layer and the presentation layer; changes in either layer are synchronized to the other.

[0056] The target digital twin is obtained based on the bidirectional data synchronization data. The target digital twin is a complete combination of the runtime carrier and all component instances, logical rules, and data synchronization mechanisms. It has three-dimensional visualization, componentization functions, business logic execution, and bidirectional data synchronization capabilities.

[0057] In this embodiment, the method further includes data-driven synchronization via a data-driven subsystem, specifically including: S71. Obtain external data source binding data based on the target digital twin, and maintain the binding relationship between the external data source and the scene object or user interface label by using data identifier as the key through data-driven business objects. S72. Obtain attribute mapping data based on the external data source binding data, and map the IoT attributes, external data table fields and twin attributes according to at least one of the following mapping modes: one-to-one, one-to-many, or many-to-one. S73. Obtain event-driven synchronization data based on the attribute mapping data, and automatically trigger twin attribute updates when external data changes, or notify external systems through application programming interface calls or event broadcasts when twin attributes change. S74. Obtain incremental update data and batch synchronization data based on the event-driven synchronization data; S75. Obtain user interface template data based on the incremental update data and the batch synchronization data, maintain the user interface template mapping through the data-driven subsystem, and dynamically generate the user interface based on the data content. S76. Obtain spatial handle data based on the user interface template data, and generate or update the position, rotation, and scaling of the twin object in the three-dimensional scene based on the spatial handle data; S77. Obtain the target digital twin after data-driven synchronization based on the space handle data.

[0058] As described in steps S71-S77 above, external data source binding data is obtained based on the target digital twin. This external data source binding data records the association between the target digital twin and the external data source. By using data-driven business objects with data identifiers as keywords, the binding relationship between the external data source and scene objects or user interface tags is maintained. Data binding based on unique keywords is a conventional existing technology. This invention adapts it to multi-source data integration scenarios for digital twins, achieving unified binding management of external data, 3D scenes, and UI interfaces.

[0059] Attribute mapping data is obtained by binding data to external data sources. This attribute mapping data defines the mapping rules between IoT attributes, external data table fields, and twin attributes, supporting at least one of one-to-one, one-to-many, or many-to-one mapping modes. One-to-one mapping means one external attribute corresponds to one twin attribute; one-to-many mapping means one external attribute corresponds to multiple twin attributes; and many-to-one mapping means multiple external attributes are used to calculate one twin attribute. This multi-mode attribute mapping adapts to complex twin data association scenarios and is the mapping configuration system of this invention for the fusion of multi-source heterogeneous data in digital twins, differing from traditional single-mode mapping. The attribute mapping data records the mapping mode, source attribute identifier, target attribute identifier, and necessary conversion formulas.

[0060] Event-driven synchronization data is obtained based on attribute mapping data. This event-driven synchronization data defines an automatic synchronization mechanism when data changes: when external data changes, the twin's attributes are automatically updated, and the latest value of the external data is written to the corresponding twin attributes according to the attribute mapping data. When the twin's attributes change, the external system is notified via application programming interface calls or event broadcasting, allowing the external system to be aware of the twin's state change. While event-driven message synchronization is a conventional technology, this invention constructs a bidirectional event linkage mechanism to achieve bidirectional data exchange between the external system and the twin, rather than the traditional one-way data reception.

[0061] Incremental update data and batch synchronization data are obtained based on event-driven synchronization data. Incremental update data records the changed fields and values ​​involved in each data change, synchronizing only the changed parts to reduce data transmission volume. Batch synchronization data aggregates multiple incremental updates into a single batch synchronization operation according to a time window, reducing the synchronization frequency and making it suitable for scenarios with high data changes. Incremental updates and batch aggregation are well-known technologies in the field of data synchronization. This invention dynamically adapts and combines the two, adaptively switching the synchronization mode according to the data change frequency, balancing real-time performance and system overhead.

[0062] User interface template data is obtained based on incremental update data and batch synchronization data. The user interface template data defines the template mapping relationship between user interface elements and data fields. The user interface template mapping is maintained by the data-driven subsystem. The user interface is dynamically generated based on the data content. When external data or twin attributes change, the user interface automatically refreshes the display content according to the template without the need to manually modify the interface code.

[0063] Spatial handle data is obtained from the user interface template data. The spatial handle data records the spatial transformation reference of the twin object in the 3D scene. The position, rotation and scaling of the twin object are generated or updated in the 3D scene based on the spatial handle data. When the external data contains spatial pose information, the spatial handle data applies the pose information to the corresponding 3D scene object to realize the real-time update of the twin's spatial position.

[0064] The target digital twin is obtained based on the spatial handle data and is synchronized with the external data source in real time. Its three-dimensional spatial pose, attribute status and user interface are automatically updated as the external data changes.

[0065] In this embodiment, the assemblable component set includes a geographic synchronization component, and the method further includes synchronizing motion states through the geographic synchronization component, specifically including the following steps: S81. Obtain the pose data packet sent by the physical entity at a historical moment based on the target digital twin, wherein the pose data packet includes at least one of device identifier, acquisition time, position, speed, acceleration, heading angle and historical control command sequence; S82. Obtain the network transmission delay based on the pose data packet, and determine whether to start spatiotemporal inversion synchronization based on the network transmission delay; S83. If started, obtain geographic information road network projection data according to the position in the pose data packet, and determine the target path segment where the physical entity is located and the mileage offset on the target path segment according to the geographic information road network projection data. S84. Obtain path geometric curvature data based on the target path segment, and obtain a set of reachable locations based on the path geometric curvature data, the historical control command sequence, and the maximum speed, maximum acceleration, and maximum jerk of the physical entity. S85. Obtain the synchronous pose of the physical entity at the current moment according to the set of reachable locations, and update the three-dimensional spatial transformation matrix of the target digital twin according to the synchronous pose.

[0066] As described in steps S81-S85 above, the pose data packets sent by the physical entity at historical moments are obtained based on the target digital twin. These pose data packets are generated and sent by the physical entity at the historical acquisition moment. Each pose data packet includes at least one of the following: device identifier, acquisition moment, position, velocity, acceleration, heading angle, and historical control command sequence. The device identifier is used to distinguish different physical entities; the acquisition moment records the sampling time of the pose data; the position records the coordinates of the physical entity in the geographic coordinate system; the velocity and acceleration record the motion state of the physical entity; the heading angle records the orientation of the physical entity; and the historical control command sequence records the control commands received by the physical entity before the acquisition moment, used to estimate the motion trend of the physical entity.

[0067] The network transmission delay is obtained based on the pose data packet. This network transmission delay is the time difference between the pose data packet being sent from the physical entity and received by the target digital twin. It is calculated by subtracting the acquisition time from the reception time, a conventional time difference calculation method and a well-known existing technology, which will not be elaborated upon here. Based on the relationship between the network transmission delay and a preset delay threshold, it is determined whether to initiate spatiotemporal inversion synchronization: when the network transmission delay exceeds the preset delay threshold, it is determined that the position data in the pose data packet has a lag deviation and cannot reflect the current true position of the physical entity, thus initiating the spatiotemporal inversion synchronization mechanism. When the network transmission delay does not exceed the preset delay threshold, the twin is directly updated using the original pose data without inversion correction. This delay determination logic is a targeted rule design of this invention adapted to real-time synchronization scenarios of digital twins.

[0068] If spatiotemporal inversion synchronization is initiated, geographic information road network projection data is obtained based on the position in the pose data packet. The global geographic coordinates of the physical entity are projected onto the standardized geographic road network model to obtain the road network projection points. This geographic projection algorithm is a conventional existing technology in the GIS field; this invention only adapts it to the scenario of motion entity trajectory constraints. Based on the geographic information road network projection data, the target path segment to which the physical entity currently belongs is accurately located. At the same time, the mileage offset of the physical entity on the target path segment is calculated. The mileage offset is the path arc distance from the projection point of the physical entity to the starting endpoint of the target path segment.

[0069] The path geometric curvature data is obtained based on the target path segment. This data records the radius of curvature and rate of change of curvature parameters across the entire target path segment, which are used to characterize the path bending constraints. By combining the path geometric curvature data, the historical control command sequence of the physical entity, and the inherent motion limit parameters of the physical entity (maximum velocity, maximum acceleration, maximum jerk), the set of reachable positions of the physical entity within the delay time window is obtained.

[0070] Among them, jerkiness is the rate of change of acceleration and is a core parameter constraining the smoothness of motion. Conventional motion simulation techniques only limit the boundaries of velocity and acceleration, without introducing jerkiness constraints. The addition of jerkiness constraints in this invention is a targeted improvement technique. The corresponding jerkiness calculation formula adopts the custom constraint formula of this invention, and the specific calculation method is as follows: ; in, Let dt be the jerk of motion, a be the instantaneous acceleration of the physical entity, da be the infinitesimal change of acceleration a, t be time, and dt be the infinitesimal change of time t.

[0071] Based on the aforementioned multi-dimensional motion constraint parameters, all spatial locations that satisfy path geometric constraints, kinematic limit constraints, and historical instruction constraints within the solution delay period are traversed to form a set of reachable locations. This set represents the solution range of all feasible locations for the physical entity at the current moment, effectively eliminating invalid location points that exceed physical limits or road network constraints.

[0072] The optimal solution is selected from the set of reachable locations as the synchronous pose of the physical entity at the current moment. The synchronous pose includes three-dimensional spatial coordinates, motion velocity, and heading attitude information. Finally, the three-dimensional spatial transformation matrix of the target digital twin is updated through the synchronous pose data to correct the pose lag and jump problems caused by network latency, thereby achieving spatiotemporal synchronization between the physical entity and the twin model.

[0073] In this embodiment, the step of obtaining the synchronization pose of the physical entity at the current moment based on the reachable location set includes: S91. Obtain trajectory start point data based on the end point of the historical control command sequence, and obtain trajectory end point feasible region data based on the reachable location set; S92. Construct objective function data based on the trajectory start-point data and the trajectory end-point feasible region data, wherein the objective function data includes at least one of the following: a jerk minimization term, a path lateral deviation minimization term, and a terminal speed matching term; S93. Obtain the path topology coupling matrix according to the target path segment, and embed the path topology coupling matrix as an inseparable hard constraint into the objective function data, so that the three-dimensional spatial pose is coupled with the geographic road network arc length parameter, and constrain the pose solution degree of freedom to a single degree of freedom evolution along the path arc length. S94. Obtain iterative inversion solution data based on the objective function data, and obtain the synchronization pose of the physical entity at the current moment based on the iterative inversion solution data; S95. Obtain residual data based on the iterative inversion solution data, generate a preloaded motion instruction for the next frame based on the residual data, update the transformation matrix of the current frame and pre-allocate the vertex buffer transformation parameters of the graphics processing unit for the next frame, and use the preloaded motion instruction for rendering when the next frame data packet has not arrived.

[0074] As described in steps S91-S95 above, the trajectory starting point data is determined based on the end position and motion state parameters of the historical control command sequence. The trajectory starting point data is the initial state of the spatiotemporal inversion trajectory calculation, including the initial position, initial velocity, initial acceleration, and initial heading angle. Based on the reachable position set obtained from the aforementioned solution, the trajectory endpoint feasible region data is constructed. The trajectory endpoint feasible region is the boundary of the set of all compliant and feasible positions of the physical entity at the current moment, providing a constraint range for subsequent optimization solutions.

[0075] Based on the trajectory start-point data and the feasible region data of the trajectory end-point, a multi-constraint coupled optimization objective function is constructed. This objective function integrates multiple optimization dimensions, which differs from traditional single trajectory optimization algorithms. The specific calculation formula is as follows: ; in, To optimize the overall objective function value, These are the jerkness weighting coefficient, path deviation weighting coefficient, and terminal speed weighting coefficient, respectively. At the starting time, For the current moment, This represents the lateral deviation of the trajectory point relative to the path centerline. To determine the deviation between the terminal speed and the measured speed.

[0076] The first term in the formula is the jerk minimization term, which ensures a smooth motion trajectory without sudden jitter. The second term is the path lateral deviation minimization term, which constrains the physical entity to conform to the road network path and reduces trajectory deviation. The third term is the terminal speed matching term, which ensures that the calculated motion state is consistent with the actual motion trend of the physical entity. The weight coefficients of the three terms can be adaptively adjusted according to different physical entity motion scenarios to adapt to the synchronous scenarios of various moving entities such as equipment and vehicles. This multi-constraint coupled optimization objective function can be used to solve the optimal smooth trajectory within the feasible domain of the reachable position of the physical entity in scenarios where network transmission delay causes pose data packet lag. It overcomes the shortcomings of traditional trajectory estimation, which lacks jerk smoothing constraints and does not combine geographical road network constraints, resulting in virtual motion trajectory jitter, deviation from the real path, and model position jumps.

[0077] Based on the road network topology and geometric parameters of the target path segment, a path topology coupling matrix is ​​constructed. This coupling matrix serves as the constraint model of this invention, establishing a strong correlation between 3D spatial rectangular coordinates and geographic road network arc length parameters. The path topology coupling matrix is ​​embedded as an inseparable hard constraint into the objective function, forcing the 3D spatial pose solution process to conform to the variation law of road network arc length. This simplifies the traditional 3D multi-degree-of-freedom pose solution problem into a single-degree-of-freedom optimization solution along the path arc length, significantly improving solution efficiency and trajectory matching accuracy. This constraint method overcomes the technical shortcomings of traditional independent 3D pose solutions without road network constraints.

[0078] Based on an optimization objective function with hard constraints, an iterative inversion optimization algorithm is used for iterative solution to obtain iterative inversion solution data. The basic iterative logic of the iterative inversion solution is a conventional technique in the field of numerical optimization, but this invention incorporates a dedicated iterative solution model constructed with road network hard constraints and multi-dimensional optimization terms, specifically designed for this purpose. Through multiple iterations and convergence, the objective function value is minimized, and the optimal arc length parameter is finally obtained. This parameter is then mapped and converted to obtain the high-precision synchronized pose of the physical entity at the current moment.

[0079] After iterative solving, the residual data of this optimization solution is obtained. The residual data is the remaining error value after the objective function converges, used to characterize the accuracy of this pose solution. Based on the residual data, the current motion trend, and historical control commands, the preloaded motion commands for the next frame are predicted and generated.

[0080] This invention employs a pre-rendering compensation mechanism, specifically: updating the 3D transformation matrix of the target digital twin in the current frame in real time, while pre-allocating the GPU vertex buffer transformation parameters for the next frame; in scenarios where subsequent physical entity pose data packets are not delivered in time or there is a brief network lag, the pre-loaded motion instructions are directly invoked for interpolation rendering, avoiding issues such as screen stuttering, pose jumps, and blank screens in the 3D scene, greatly improving the continuity and stability of motion synchronization in digital twin visualization.

[0081] In summary, this invention enables standardized, visualized, and rapid assembly of digital twins through a modular component architecture. By employing a multi-condition logic configuration system, a bidirectional data-driven synchronization mechanism, and a road network-constrained spatiotemporal inversion pose optimization algorithm, it solves the technical problems of poor compatibility, low configuration flexibility, data synchronization lag, and motion trajectory distortion in traditional digital twin assembly. The overall methodology is standardized, highly implementable, and adaptable to the visualized assembly and real-time synchronization applications of digital twins in various industrial and geographical scenarios.

[0082] This invention also discloses a digital twin system based on a modular component architecture, comprising: The first acquisition module is used to acquire the physical entity object metadata and functional component configuration metadata of the digital twin to be assembled; The second acquisition module is used to acquire unified component interface data based on the physical entity object metadata, and acquire a set of assembleable components and component metadata based on the unified component interface data. The merging module is used to obtain component attribute data and logical rule data according to the configuration metadata of the functional components, and to associate and merge the component attribute data and the logical rule data with the set of assembleable components to obtain a modular component data chain. The model acquisition module is used to acquire visual assembly data based on the modular component data chain, and to acquire the twin data model to be instantiated based on the visual assembly data. The assembly module is used to perform similarity matching between the twin data model to be instantiated and the preset component assembly template when the twin data model to be instantiated is not in the preset component assembly template, to obtain a similar assembly template, and to supplement the similar assembly template with component semantics based on the visualized assembly data to obtain a newly defined component assembly template. The processing module is used to instantiate and visually assemble the digital twin to be assembled at runtime according to the newly defined component assembly template, so as to obtain the target digital twin.

[0083] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0084] The above description is merely a preferred embodiment of the present invention and does not limit the scope of this application. Any equivalent results or equivalent process transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of protection of this application.

Claims

1. A digital twin visualization assembly method based on a modular component architecture, characterized in that, Includes the following steps: Obtain the physical entity object metadata and functional component configuration metadata of the digital twin to be assembled; Based on the physical entity object metadata, obtain unified component interface data, and based on the unified component interface data, obtain the set of assembleable components and component metadata; Component attribute data and logical rule data are obtained based on the configuration metadata of the functional components, and the component attribute data and logical rule data are associated and merged with the set of assembleable components to obtain a modular component data chain; Visual assembly data is obtained based on the modular component data chain, and a twin data model to be instantiated is obtained based on the visual assembly data. When the twin data model to be instantiated is not within the preset component assembly template, the twin data model to be instantiated is matched with the preset component assembly template to obtain a similar assembly template, and the similar assembly template is supplemented with component semantics based on the visualized assembly data to obtain a newly defined component assembly template. The target digital twin is obtained by runtime instantiation and visual assembly of the digital twin to be assembled according to the newly defined component assembly template.

2. The digital twin visualization assembly method based on a modular component architecture according to claim 1, characterized in that, The steps of obtaining unified component interface data based on the physical entity object metadata, and obtaining a set of assemblable components and component metadata based on the unified component interface data, include: Obtain component interface specification data based on the metadata of the physical entity object; According to the component interface specification data, obtain unified component interface data, wherein the unified component interface data is used to define a unified component interface, and the unified component interface requires the component to inherit from the scene component and implement the unified component interface. Type safety conversion data is obtained based on the unified component interface data, and type safety conversion is performed between the scene component and the unified component interface based on the type safety conversion data to obtain component type safety data; Based on the component type security data, obtain the component attribute object, and based on the component attribute object, obtain at least one attribute polymorphic data from the current value, previous value, difference, default value, maximum value, change timestamp, and change interval; Component clone data is obtained based on the attribute polymorphic data, and component instances are obtained based on the component clone data; Component metadata is obtained based on the component instance, and the component metadata includes at least one of component name, category, icon, description, and production availability flag; The set of assembleable components is obtained based on the component metadata and the unified component interface data.

3. The digital twin visualization assembly method based on a modular component architecture according to claim 1, characterized in that, The step of associating and merging the component attribute data and the logical rule data with the set of assemblable components to obtain a modular component data chain includes: The digital twin data layer structure is obtained based on the component attribute data, the logical rule data, and the set of assembleable components. The digital twin data layer structure is organized in a tree structure and includes a root node, component nodes, and logical rule nodes. Based on the digital twin data layer structure, obtain shared pointer management data, and perform reference counting management on the digital twin data layer structure, component attribute objects, component data objects, and logical rule objects based on the shared pointer management data; Dirty flag data is obtained according to the digital twin data layer structure, and the dirty flag is set to true when a component is added, a component is deleted, or an attribute changes, and the dirty flag is set to false after loading from disk, based on the dirty flag data. Serialized data is obtained based on the dirty tag data, and JSON serialization and deserialization are performed on the serialized data through the serialization interface and deserialization interface. The modular component data chain is obtained based on the digital twin data layer structure and the serialized data.

4. The digital twin visualization assembly method based on a modular component architecture according to claim 1, characterized in that, The step of obtaining visual assembly data based on the modular component data chain includes: The component library registration data is obtained according to the modular component data chain, and the components that implement the unified component interface are scanned and registered through the automatic registration interface of the visual assembly editor subsystem to obtain the component library. Obtain drag-and-drop assembly data from the component library, and drag and drop components from the component library to the temporary editing host based on the drag-and-drop assembly data, generate component instances and assign unique identifiers, parent-child relationship identifiers and display order; Attribute editing data is obtained based on the component instance, and attribute editing interfaces are generated according to a three-level priority. The attribute editor generator registered by the visual assembly editor subsystem has a higher priority than the component-specific editing panel generation interface, and the component-specific editing panel generation interface has a higher priority than the default editing interface automatically generated based on the attribute definition. Logical graphical configuration data is obtained by editing the data based on the attributes; The visual assembly data is obtained based on the logical graphical configuration data.

5. The digital twin visualization assembly method based on a modular component architecture according to claim 4, characterized in that, The logical rule data is graphically configured through logical rule objects, and the specific acquisition steps include: Based on the configuration metadata of the functional components, condition set data and action set data are obtained, and the condition set data and action set data are associated and merged to obtain condition-action logic data; Based on the condition-action logic data, obtain multi-condition combination data, and perform at least one logical operation among AND, OR, and NOT based on the multi-condition combination data; Condition type data is obtained based on the multi-condition combination data, wherein the condition type data includes at least one of the following: change condition, equal condition, growth condition, decrease condition, greater than condition, greater than or equal to condition, less than condition, less than or equal to condition, modulo condition, and multiple condition; The action type data is obtained based on the condition-action logic data, wherein the action type data includes at least one of the actions of modifying component attributes and calling external interfaces; Obtain action chain data based on the action type data, and perform at least one of immediate execution, delayed execution, and exception handling based on the action chain data; Numerical range mapping data is obtained based on the condition-action logic data, and the mapping relationship between attribute value ranges and multiple target values ​​is defined through attribute value range mapping items; The logical rule data is obtained based on the numerical interval mapping data.

6. The digital twin visualization assembly method based on a modular component architecture according to claim 1, characterized in that, The step of instantiating and visually assembling the digital twin to be assembled at runtime according to the newly defined component assembly template to obtain the target digital twin includes: According to the newly defined component assembly template, a data copy of the twin data model to be instantiated is obtained through the instance acquisition interface; A runtime carrier is obtained based on the data copy, and the target digital twin is instantiated based on the runtime carrier; Component clone data is obtained based on the runtime carrier, and component instances are created in batches based on component templates through the component clone interface; Bidirectional data synchronization data is obtained based on the component instance, and bidirectional data synchronization is performed between the data layer and the presentation layer through at least one of the data loading interface, data saving interface, cloning interface, deserialization interface and serialization interface; The target digital twin is obtained based on the bidirectional data synchronization data.

7. The digital twin visualization assembly method based on a modular component architecture according to claim 1, characterized in that, The method also includes data-driven synchronization via a data-driven subsystem, specifically including: Based on the target digital twin, external data source binding data is obtained, and data-driven business objects are used with data identifiers as keywords to maintain the binding relationship between external data sources and scene objects or user interface labels. Attribute mapping data is obtained based on the external data source binding data, and IoT attributes, external data table fields and twin attributes are mapped according to at least one of the following mapping modes: one-to-one, one-to-many or many-to-one. Event-driven synchronization data is obtained based on the attribute mapping data, and the twin attribute is automatically triggered to update when external data changes, or the external system is notified through application interface calls or event broadcasts when the twin attribute changes. Incremental update data and batch synchronization data are obtained based on the event-driven synchronization data; The user interface template data is obtained based on the incremental update data and the batch synchronization data, and the user interface template mapping is maintained through the data-driven subsystem to dynamically generate the user interface based on the data content. Based on the user interface template data, spatial handle data is obtained, and the position, rotation, and scaling of the twin object are generated or updated in the 3D scene based on the spatial handle data. The target digital twin is obtained after data-driven synchronization based on the spatial handle data.

8. The digital twin visualization assembly method based on a modular component architecture according to claim 1, characterized in that, The set of configurable components includes a geographic synchronization component, and the method further includes synchronizing motion states through the geographic synchronization component, specifically including the following steps: Based on the target digital twin, obtain the pose data packet of the physical entity at a historical moment, wherein the pose data packet includes at least one of the following: device identifier, acquisition time, position, velocity, acceleration, heading angle, and historical control command sequence; The network transmission delay is obtained based on the pose data packet, and the decision on whether to initiate spatiotemporal inversion synchronization is made based on the network transmission delay. If started, geographic information road network projection data is obtained based on the position in the pose data packet, and the target path segment where the physical entity is located and the mileage offset on the target path segment are determined based on the geographic information road network projection data. Obtain path geometric curvature data based on the target path segment, and obtain a set of reachable locations based on the path geometric curvature data, the historical control command sequence, and the maximum speed, maximum acceleration, and maximum jerk of the physical entity; The synchronized pose of the physical entity at the current moment is obtained based on the set of reachable locations, and the three-dimensional spatial transformation matrix of the target digital twin is updated based on the synchronized pose.

9. The digital twin visualization assembly method based on a modular component architecture according to claim 8, characterized in that, The step of obtaining the synchronized pose of the physical entity at the current moment based on the set of reachable locations includes: The trajectory start point data is obtained based on the end point of the historical control command sequence, and the trajectory end point feasible region data is obtained based on the reachable location set. Objective function data is constructed based on the trajectory start-point data and the trajectory end-point feasible region data, wherein the objective function data includes at least one of the following: a jerk minimization term, a path lateral deviation minimization term, and a terminal velocity matching term; The path topology coupling matrix is ​​obtained based on the target path segment, and the path topology coupling matrix is ​​embedded as an inseparable hard constraint into the objective function data, so that the three-dimensional spatial pose is coupled with the geographic road network arc length parameter, and the pose solution degree of freedom is constrained to a single degree of freedom evolution along the path arc length. The iterative inversion solution data is obtained based on the objective function data, and the synchronization pose of the physical entity at the current moment is obtained based on the iterative inversion solution data. Residual data is obtained based on the iterative inversion solution data, and a preloaded motion instruction for the next frame is generated based on the residual data. The transformation matrix of the current frame is updated and the vertex buffer transformation parameters of the graphics processing unit for the next frame are pre-allocated. The preloaded motion instruction is used for rendering when the next frame data packet has not arrived.

10. A digital twin system based on a modular component architecture, characterized in that, include: The first acquisition module is used to acquire the physical entity object metadata and functional component configuration metadata of the digital twin to be assembled; The second acquisition module is used to acquire unified component interface data based on the physical entity object metadata, and acquire a set of assembleable components and component metadata based on the unified component interface data. The merging module is used to obtain component attribute data and logical rule data according to the configuration metadata of the functional components, and to associate and merge the component attribute data and the logical rule data with the set of assembleable components to obtain a modular component data chain. The model acquisition module is used to acquire visual assembly data based on the modular component data chain, and to acquire the twin data model to be instantiated based on the visual assembly data. The assembly module is used to perform similarity matching between the twin data model to be instantiated and the preset component assembly template when the twin data model to be instantiated is not in the preset component assembly template, to obtain a similar assembly template, and to supplement the similar assembly template with component semantics based on the visualized assembly data to obtain a newly defined component assembly template. The processing module is used to instantiate and visually assemble the digital twin to be assembled at runtime according to the newly defined component assembly template, so as to obtain the target digital twin.

Images