Packaging method for digital twin virtual equipment modeling and production unit combination

Abstract

The invention relates to a packaging method for modeling and production unit combination of digital twin virtual equipment, which realizes modeling of the virtual equipment through an abstract process from top to bottom, and ensures high cohesion packaging of key attributes, states and behaviors of the virtual equipment in combination with an information hiding and uniform interface mechanism. A production unit-level combination and hierarchical packaging framework is further constructed based on the equipment model, and recursive combination and interoperation of multiple layers of modules are realized through unified station-level, production line-level and workshop-level interfaces and scheduling logic; according to the method, the modeling and packaging process of the digital twin virtual equipment is defined, the high cohesion packaging and interface uniformity of the model are highlighted, and cross-level combination and scheduling logic design are supported, so that the consistency and the implementability of the model in the system integration, evolution extension and module multiplexing processes are remarkably improved, and the modeling efficiency of the digital twin virtual equipment is improved. And universal and normalized technical support is provided for hierarchical construction and efficient deployment of virtual equipment in an intelligent manufacturing system.

Description

Technical Field

[0001] The present invention relates to a packaging method for digital twin virtual equipment modeling and production unit combination, belonging to the technical field of digital twin and virtual debugging. Background Art

[0002] As the manufacturing industry transitions toward intelligence, digitization, and flexibility, virtual commissioning of production units based on digital twins has become a key technical approach to ensuring the performance and reliability of next-generation intelligent manufacturing systems. Digital twin technology precisely replicates the structure, behavior, and interactions of physical equipment in a virtual space, providing a simulation and verification platform for the commissioning process. Virtual commissioning, an application of digital twins, builds digital twin models of equipment, enabling the detection of design flaws through simulation and verification in a virtual environment before physical equipment is deployed on-site. However, existing methods often present the internal state and control logic of equipment in a decentralized and exposed manner, lacking unified modeling standards and hierarchical combination mechanisms. This results in poor system maintainability, limited scalability, and difficulty meeting the requirements of large-scale, cross-level virtual commissioning. To address these issues, this paper proposes a packaging method for digital twin virtual device modeling and production unit assembly. Through a top-down abstract process, information hiding, a unified interface mechanism, and a multi-level packaging architecture, a modular, highly cohesive, and low-coupling multi-level modeling system is implemented, providing an efficient, reusable, and easily maintainable solution for the virtual commissioning of intelligent manufacturing systems. Summary of the Invention

[0003] The present invention is aimed at the problems existing in the prior art and provides a packaging method for digital twin virtual device modeling and production unit combination. The method includes a top-down abstract process, information hiding and unified interface mechanism, and a multi-level packaging architecture, realizing a modular, highly cohesive and low-coupling multi-level modeling system.

[0004] To achieve the above objectives, the technical solution of the present invention is as follows: a packaging method for digital twin virtual device modeling and production unit combination, the method comprising the following steps:

[0005] Step 1: Package modeling of virtual devices,

[0006] Step 2: Produce unit-level combination and hierarchical packaging;

[0007] or

[0008] Step 2: Hierarchical packaging and production unit-level combination; In step 2 of this solution, the production unit-level combination and hierarchical packaging can be adjusted in sequence according to actual needs to meet the needs of different situations.

[0009] The encapsulation modeling of virtual device classes usually follows a top-down abstraction process, with the following main steps:

[0010] A. Analyze the functions and components of the physical device. Systematically identify and analyze the components of the actual device, clarify the subsystems within the device and their functions, and clarify their dynamic characteristics and interactions. This step is the basis for virtual device encapsulation.

[0011] B. Determine internal states and attributes. Define the internal state variables and key attributes of the virtual device model based on the analysis results. These states and attributes must accurately reflect the operating conditions of the actual device under different operating conditions.

[0012] C. Design a unified interface. Define a unified input and output interface for the virtual device model, abstract sensor data input and actuator control command output, and ensure a clear and standardized interface for interaction between devices.

[0013] D encapsulates behavioral logic. Based on the device's functions and interfaces, the device's operating logic is encapsulated as class methods or rules. These logics are invisible to the outside world and are used to implement device status updates and function execution through unified interface calls.

[0014] E-Verification and iterative optimization. Use simulation platforms or compare with actual device data for verification to ensure that the virtual device model is consistent with the actual device behavior in terms of status updates, event feedback, etc., and continuously optimize model parameters and logic to improve model accuracy;

[0015] The information hiding mechanism and interface unification mechanism need to be used in the virtual device encapsulation modeling process:

[0016] Mechanism 1: The information hiding mechanism ensures that the virtual device content is invisible to the outside world, reducing coupling between modules. This mechanism can hide internal states, algorithms, and control logic, and control access rights to interfaces.

[0017] Mechanism 2: The interface unification mechanism enables different modules of the system to communicate and collaborate in a consistent and compatible manner through standardized device interaction protocols. This mechanism can improve the convenience of virtual device integration and the scalability of the system, and realize plug-and-play of device models.

[0018] Production unit-level combination and hierarchical encapsulation are based on virtual device encapsulation, further realizing abstract encapsulation and combination from the device level to the production unit level, and are an important part of digital twin system modeling. Specifically, they include two methods: production unit-level combination and hierarchical encapsulation:

[0019] Step 2: Production unit level combination method

[0020] The essence of the production unit-level composition method is to effectively integrate several collaborative virtual device instances to form a production unit-level module that can independently complete a specific function or task. The composition process should follow a clear modeling process:

[0021] A. Determine the functional boundaries and encapsulation interfaces of the production units: First, clearly define the overall functional boundaries of the production units to be combined, such as assembly, handling, and testing. External interfaces should reflect the functional abstraction of the production unit as a whole, typically including operation interfaces such as start, stop, and status query. These interfaces shield the underlying device details, ensuring that external systems can manage and access the production units in a unified and concise manner.

[0022] B. Define the interactions between devices within the production unit: After defining the overall interface, design the internal call relationships and data interaction methods for each virtual device. Establish a collaborative call flow and data transfer mechanism between devices to ensure that each device works together according to the predetermined process. Use flowcharts and sequence diagrams to describe in detail the triggering conditions, call relationships, and data flows between devices to achieve efficient and orderly internal interactions.

[0023] C. Establishing production unit-level control logic: After designing the device interaction relationships, the production unit-level control logic needs to be encapsulated within the unit. This control logic is implemented through an internal management class, which encapsulates the overall production unit operation sequence, inter-device coordination logic, and exception handling mechanisms. External systems do not need to understand the specific interactions between devices within the unit; they only need to manage them through the unit controller interface.

[0024] Step 2: Hierarchical packaging method

[0025] In this solution, the hierarchical encapsulation method, based on the completion of the production unit combination, further abstracts and combines multiple production unit-level encapsulation modules to a higher level, forming an abstract encapsulation structure at the production line and even workshop level, forming a multi-level digital twin modeling system. Its implementation steps include defining a hierarchical encapsulation model structure, building a hierarchical interaction interface and coordination mechanism, and multi-level abstraction and recursive encapsulation. The specific steps of the hierarchical encapsulation method are as follows:

[0026] A defines a hierarchical encapsulation model structure:

[0027] 1. After completing the production unit level combination, build a production line level packaging model. The production line level packaging model corresponds to a complete production line entity, which is recorded as the ProductionLine class;

[0028] 2. The ProductionLine class encapsulates several production unit modules as component submodules. Each production unit module is an encapsulation implemented by the WorkUnit class in the previous step.

[0029] 3 The ProductionLine class maintains the following member variables:

[0030] 3.1 Module Registry, used to dynamically store and manage metadata information of each sub-module, including module identification, function description, and input / output interface definition;

[0031] 3.2 Ordered submodule list List <workunit>workUnits, which contain all

[0032] There are production unit module instances;

[0033] 4 The ProductionLine class only exposes the following unified production line interface:

[0034] 4.1startLine()——Start the entire production line and trigger the startUnit() of each internal submodule in turn;

[0035] 4.2stopLine()——Stop the entire production line and call stopUnit() of each submodule in reverse order to ensure safe shutdown;

[0036] 4.3getLineStatus()——aggregates and returns the operating status and performance indicators of each submodule, providing high-granularity overall status of the production line.

[0037] State feedback;

[0038] 5. The specific implementation details of the submodules are shielded within the ProductionLine class. When the above unified interface is called externally, the device-level entities within the submodules cannot be directly accessed or modified. The overall control and monitoring of the production line can only be completed through the startLine(), stopLine(), and getLineStatus() interfaces.

[0039] 6 At a higher level, the production line-level packaging model can be used as a subcomponent of the Workshop or higher-level model, and recursively embedded through the same packaging and interface design principles to achieve multi-level abstraction and unified management.

[0040] B. Build a hierarchical interactive interface and coordination mechanism: At the production line level, a unified hierarchical coordination control logic needs to be designed, namely, the production scheduling and coordination logic encapsulated within the production line model. This logic is used to organize the collaboration and information exchange between various production unit modules, such as the data and event exchange relationship between upstream and downstream units. It also includes cross-unit coordination mechanisms for abnormal or emergency situations. For example, when a unit fails, the entire production line is shut down or a backup plan is triggered.

[0041] The specific construction of the hierarchical interactive interface and coordination mechanism is as follows:

[0042] 1. Set up an information event bus within the ProductionLine class to implement command issuance and status reporting between production units, support synchronous control and asynchronous notification, and handle data format differences through the adaptation layer to ensure transparent communication between modules.

[0043] 2. Establish module dependencies and schedule submodules according to the process flow sequence, supporting multiple scheduling strategies for unified control. When an exception occurs, the event bus triggers a coordinated response, including coordinated shutdown, backup path switching, degraded operation, or automatic retry, and dynamically processes and provides feedback based on the configuration.

[0044] 3. Collect the running status of each module in a unified manner, provide overall status interface and event subscription, and support real-time monitoring and historical tracing.

[0045] Scheduling strategies and exception handling are dynamically adjusted through configuration files, supporting online updates and security permission control.

[0046] 4ProductionLine can be embedded in a higher-level model as a subcomponent. ProductionLine can be embedded in a Workshop or higher-level model as a subcomponent. The upper layer only uses high-granularity interfaces (such as startWorkshop() and getWorkshopStatus()).

[0047] Management is performed without having to worry about the details of internal interactions. The same mechanism can be reused at higher levels, forming a complete hierarchical interaction and coordination system from the device level to the workshop level and even the factory level. Hierarchical collaboration and abstract management are achieved through a unified interface and event upload.

[0048] C multi-level abstraction and recursive encapsulation:

[0049] The multi-level abstraction and recursive encapsulation are as follows:

[0050] 1 Define the workshop-level packaging model Workshop at a higher level and manage multiple production line-level packaging models (ProductionLine) as sub-modules.

[0051] 2Workshop only exposes unified workshop-level interfaces, such as startWorkshop(), stopWorkshop(), and getWorkshopStatus(), shielding the specific details of the lower-level production lines and units.

[0052] 3. The workshop maintains a list of production lines and their metadata information, supports dynamic management and status aggregation, and realizes unified scheduling and monitoring of production lines.

[0053] 4. The workshop-level model has the ability to coordinate abnormalities. When a production line fails, it can trigger a coordinated shutdown or backup plan to ensure the continuity of overall production.

[0054] 5 According to the principle of recursive encapsulation, Workshop can be embedded as a submodule of a higher-level system, supporting multi-level and multi-level unified management and scheduling, achieving the goal of clear system abstraction levels and low coupling.

[0055] This recursive encapsulation method makes the system abstraction level clear, facilitating high-level planning, scheduling, and management without having to drill down to low-level details.

[0056] The encapsulation method for digital twin virtual device modeling and production unit combination is suitable for providing an efficient and reusable modeling method for virtual debugging systems. By encapsulating virtual devices, this method requires encapsulating the key attributes, status, and behavior of the device in an independent class and providing standardized input and output interfaces to the outside world. Then, based on the device model, a combination model at the production unit level is constructed, and further expanded to a multi-level encapsulation system to form a complete digital twin modeling structure from equipment to production line to workshop. This method not only simplifies the conversion process from physical equipment to virtual models and improves modeling efficiency, but also significantly reduces the coupling between models through strict information hiding and interface unification mechanisms, avoiding errors in repeated modeling and manual integration.

[0057] Compared with the existing technology, the present invention has the following significant advantages: the packaging method of the present invention for digital twin virtual device modeling and production unit combination can modularly model virtual devices from top to bottom and, on this basis, combine and encapsulate production units and higher levels, thereby forming a multi-level digital twin virtual device model with a clear structure; the introduction of information hiding and unified interface mechanism not only ensures low coupling and plug-and-play between modules, but also supports the shielding and reuse of lower-level implementation details by the upper-level model; at the same time, through verification and iterative optimization by comparison with the simulation platform or actual device data, it ensures that the virtual device model is consistent with the actual device behavior in terms of status update, event feedback, etc., and continuously optimizes model parameters and logic to improve model accuracy, thereby effectively improving the virtual device model accuracy and system reliability, thereby greatly improving modeling efficiency and reducing subsequent maintenance costs, providing solid technical support for the rapid deployment and expansion of large-scale digital twin systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 A schematic diagram of the object-oriented encapsulation modeling process of the present invention;

[0059] Figure 2 This is a schematic diagram of the production line unit level assembly of the present invention;

[0060] Figure 3 This is a schematic diagram of the hierarchical packaging of the production line of the present invention. DETAILED DESCRIPTION

[0061] In order to deepen the understanding of the present invention, this embodiment is described in detail below with reference to the accompanying drawings.

[0062] Example:

[0063] Figure 1 As shown in the figure, the virtual device modeling method based on object-oriented encapsulation has the following modeling process:

[0064] A. Analyze the function and composition of the physical equipment and identify that the riveting press is composed of key components such as pressure sensor, displacement sensor, hydraulic cylinder, riveting head and fixture;

[0065] B determines the internal state and attributes, abstracts the core states of the riveting press, such as real-time pressure value, real-time displacement value, and core functions such as starting riveting and cylinder advancement;

[0066] C designs a unified interface, mapping the above functional elements to a virtual device class called RivetMachine. Attributes such as pressure and displacement are set to private for internal state management, while methods such as initiateClamp() and releaseClamp() are set to public to provide external control capabilities as a unified interface.

[0067] D encapsulates the behavior logic and writes the logic for updating the status after the pressure and position reach the predetermined values ​​inside startRivet();

[0068] E-verification and iterative optimization: compare the running data in the virtual simulation platform with the actual equipment test data to continuously optimize the accuracy of the virtual model.

[0069] Among them, the encapsulation modeling method of virtual devices means encapsulating the key attributes, states and behaviors of the device in independent classes, and realizing modularization, high cohesion and low coupling through information hiding and unified interface mechanisms; relying on a top-down abstract process: analyzing entity functions and composition, determining internal states and attributes, designing unified interfaces, encapsulating behavioral logic, verification and iterative optimization; combined with simulation verification, to ensure the model's accurate mapping of the dynamic characteristics of physical devices and maintainability.

[0070] The virtual device modeling process based on object-oriented encapsulation requires the use of information hiding mechanism and interface unification mechanism:

[0071] Mechanism 1: An information hiding mechanism ensures that the virtual device's implementation is invisible to the outside world, reducing coupling between modules. This mechanism can hide internal state, algorithms, and control logic, and control interface access rights. The above embodiment sets internal state attributes such as pressure and displacement, as well as specific behavior logic, as private, providing limited external access only through controlled interfaces. This shields implementation details and reduces module coupling.

[0072] Mechanism 2: The interface unification mechanism enables different modules of the system to communicate and collaborate in a consistent and compatible manner through standardized device interaction protocols. This mechanism can improve the convenience of virtual device integration and the scalability of the system, and realize plug-and-play of device models. The above embodiment uniformly defines public methods such as initateClamp(), releaseClamp(), and startRivet() for the riveting press virtual device, ensuring that external systems can interact with the device with consistent semantics and calling methods, realizing plug-and-play and high scalability of modules.

[0073] Based on the above-mentioned virtual device encapsulation of the riveting press, we further implement abstract encapsulation and combination from the device level to the production unit level, namely production unit level combination and hierarchical encapsulation. Specifically, we can include two methods of production unit level combination and hierarchical encapsulation:

[0074] Step 2: Production unit level combination method

[0075] Figure 2 As shown in the figure, the production unit level combination process of the riveting press should follow the following clear modeling process:

[0076] A. Determine the functional boundaries and encapsulation interfaces of the production units: First, clarify the overall functional boundaries that the production units to be combined must achieve. In the riveting station, the unit functional boundary is clearly defined as the "riveting task." The combined model should expose a unified start and stop operation interface (startWorkUnit(), stopWorkUnit()) and a status query interface (getUnitStatus()). The interface defined at this stage is different from the underlying device interface and focuses more on the abstraction of the overall function of the entire unit rather than the functional details of a single device.

[0077] B. Clarify the interaction between devices within the production unit: After defining the overall interface, it is necessary to design the internal call relationships and data interaction methods of each virtual device. In the riveting station, the fixture controller is responsible for positioning and clamping the workpiece, the riveting press completes the riveting operation, and the conveyor mechanism is responsible for loading and unloading and transporting the workpiece. These devices collaborate through a clear interface call sequence and data exchange. To this end, a clear device call flow chart and timing diagram should be designed to clarify the call sequence, conditions, and data interaction methods between each device;

[0078] C. Establishing the production unit-level control logic: After completing the design of the equipment interaction relationship, the production unit-level control logic needs to be encapsulated within the unit. In the riveting station, WorkUnitController implements a simple interaction by exposing only three interfaces: startWorkUnit(), stopWorkUnit(), and getUnitStatus(), through unified management of the three submodules: the fixture controller, the riveting press, and the conveyor mechanism. Among them, startWorkUnit() internally calls the logical interfaces such as FixtureController.positionWorkpiece() to complete workpiece positioning, RivetMachine.startRivet() to execute press assembly, and Conveyor.startTransfer() to transport the workpiece. At the same time, readiness checks are performed at each step through status feedback to ensure seamless process connection. stopWorkUnit() issues a stop command in reverse order, while getUnitStatus() summarizes the status of each submodule and returns the overall operation results and fault information, thus realizing the timing arrangement, status coordination, and unified monitoring of the production unit.

[0079] Step 2: Hierarchical packaging method

[0080] Figure 3 The specific steps of the workshop-level hierarchical packaging method are as follows:

[0081] A defines a hierarchical encapsulation model structure: Figure 3 In the workshop-level model shown, we first define a hierarchical encapsulation model structure to encapsulate the specific production line and its workstations into the workshop-level framework. Taking production line A as an example, we construct the corresponding ProductionLineA class:

[0082] 1. After completing the combination of several production units, instantiate ProductionLineA, which encapsulates multiple station-level modules, such as assembly stations, inspection stations, and packaging stations. Each station module is an instance of the WorkUnit class previously encapsulated.

[0083] 2.ProductionLineA maintains the module registry ModuleRegistry internally, which records the identification, functional description, and input / output interface definitions of assembly stations, inspection stations, and packaging stations. It also maintains the ordered submodule list workUnits, which is arranged in sequence according to the process flow and serves as the basis for starting, stopping, and status aggregation.

[0084] 3ProductionLineA only exposes the unified interface:

[0085] startLine(): triggers the startUnit() of each station in sequence according to the order of assembly → inspection → packaging or parallel strategy;

[0086] stopLine(): Call stopUnit() of each station in reverse order to ensure that all work-in-progress parts are safely stopped or unloaded;

[0087] getLineStatus(): aggregates the operating status, capacity indicators, and fault information of each workstation to provide overall feedback on the production line;

[0088] 4ProductionLineA internally shields the specific equipment details of each workstation. The upper layer or external control and monitoring of the entire production line can only be carried out through the above interfaces, avoiding dependence on the internal implementation of the assembly mechanism, inspection system or packaging device;

[0089] 5. At a higher level, ProductionLineA is introduced as a subcomponent into the workshop-level model Workshop and recursively embedded according to the encapsulation and interface design principles to achieve unified management of multiple production lines.

[0090] B builds a hierarchical interactive interface and coordination mechanism within ProductionLineA to organize collaboration and exception linkage among workstations:

[0091] 1. Through a lightweight information / event bus, messages such as start, stop, and status reporting are transmitted between assembly stations, inspection stations, and packaging stations. The adaptation layer can convert data formats or units between different stations when needed to ensure transparent communication.

[0092] 2. Establish workstation dependencies, and the scheduling engine calls the startup interface of each workstation in this order or in parallel, and supports priority or parallel processing when necessary;

[0093] 3. When an exception occurs at a workstation, the event bus immediately reports it to ProductionLineA. Pre-configured policies determine the following: subsequent workstations may be stopped in reverse order, backup workstations may be switched, the process may be adjusted, a retry may be performed, or the process may be paused and operations and maintenance may be notified. The processing results are fed back through a unified status interface.

[0094] 4. Periodically or when triggered by an event, each workstation reports key operating indicators, which are aggregated using getLineStatus() to provide a real-time overview to the workshop level or monitoring system. Scheduling strategies and exception handling rules are maintained in configuration files, can be adjusted online, and support permission verification and secure communication.

[0095] After 5ProductionLineA is embedded in Workshop, the upper layer only needs to call high-granularity interfaces such as startWorkshop() and getWorkshopStatus() to uniformly manage multiple production lines without having to understand the internal interaction details between each workstation. This mechanism can be reused at higher levels, forming a complete interaction and coordination system from the equipment level to the workstation level, production line level, workshop level, and even factory level.

[0096] C Multi-level abstraction and recursive encapsulation: Multi-level abstraction and recursive encapsulation are performed in the workshop-level model Workshop:

[0097] 1. Manage ProductionLineA, ProductionLineB, and other subcomponents as a unified system. Workshop only exposes interfaces such as startWorkshop(), stopWorkshop(), and getWorkshopStatus(), shielding the specific details of each production line and its workstations.

[0098] 2. The workshop maintains a registry and list of each production line, supporting dynamic start and stop, status aggregation, and cross-line scheduling. When a production line fails, Workshop can implement cross-line shutdown or resource reallocation based on pre-configured strategies to ensure overall production continuity.

[0099] 3. According to the recursive principle, Workshop can be embedded as a higher-level subcomponent. Through the same encapsulation and interface design, the goal of clear system abstraction level and low coupling can be achieved. Upper-level callers only need to trigger start, stop or query status through the high-level interface, without having to worry about the implementation details of the underlying workstations and equipment.

[0100] In summary, by adopting the object-oriented encapsulation modeling method for the riveting press station and the production line where it is located, the key states and behavioral logic are highly cohesively encapsulated in the RivetMachine class, and the information hiding and interface unified mechanism are used to complete the multi-level encapsulation and recursive combination of virtual equipment, production units, production lines and workshops, thereby realizing a complete digital twin system from equipment to workshop, effectively improving the system's maintainability, scalability and operational reliability.

[0101] It should be noted that the above embodiments are not intended to limit the scope of protection of the present invention, and equivalent changes or substitutions made on the basis of the above technical solutions fall within the scope of protection of the claims of the present invention.< / workunit>

Claims

1. A packaging method for digital twin virtual device modeling and production unit combination, characterized in that: The method comprises the following steps: Step 1: Package modeling of virtual devices, Step 2: Produce unit-level combination and hierarchical packaging; or Step 2: Hierarchical packaging and production unit-level combination.

2. The packaging method for digital twin virtual device modeling and production unit combination according to claim 1 is characterized in that: in, The encapsulation modeling of the virtual device class in step 1 follows a top-down abstraction process. The main steps include: A. Analyze the functions and composition of the physical device, systematically identify and analyze the various components of the actual device, clarify the subsystems within the device and their functions, and clarify their dynamic characteristics and interactive relationships. This step is the basis for virtual device encapsulation; B. Determine the internal state and attributes. Define the internal state variables and key attributes of the virtual device model based on the analysis results. These states and attributes must be able to accurately reflect the operating status of the actual device under different working conditions. C designs a unified interface to define a unified input and output interface for the virtual device model, abstracting sensor data input and actuator control command output to ensure a clear and standardized interface for interaction between devices; D encapsulates behavioral logic. Based on the device's functions and interfaces, it encapsulates the device's operating logic into class methods or rules. This logic is invisible to the outside world and implements device status updates and function execution through unified interface calls. E verification and iterative optimization, using simulation platforms or comparing with actual device data for verification, ensures that the virtual device model is consistent with the actual device behavior in terms of status updates, event feedback, etc., and continuously optimizes model parameters and logic to improve model accuracy.

3. The packaging method for digital twin virtual device modeling and production unit combination according to claim 2 is characterized in that: in, The information hiding mechanism and interface unification mechanism need to be used in the packaging modeling process of virtual devices. Mechanism 1: The information hiding mechanism ensures that the virtual device content is invisible to the outside world, reducing coupling between modules. This mechanism can hide internal states, algorithms, and control logic, and control access rights to interfaces. Mechanism 2: The interface unification mechanism enables different modules of the system to communicate and collaborate in a consistent and compatible manner through standardized device interaction protocols. This mechanism can improve the convenience of virtual device integration and the scalability of the system, and realize plug-and-play of device models.

4. The packaging method for digital twin virtual device modeling and production unit combination according to claim 3 is characterized in that: In step 2, the production unit level combination is as follows: A. Determine the functional boundaries and encapsulation interfaces of the production units: First, clarify the overall functional boundaries that the production units to be combined need to achieve. B. Clarify the interaction relationship between devices within the production unit: After clarifying the overall interface, it is necessary to design the calling relationship and data interaction method within each virtual device. C. Establishing production unit-level control logic: After completing the design of the equipment interaction relationship, the production unit-level control logic needs to be encapsulated within the unit. This control logic is implemented through the internal management class, which encapsulates the overall operating sequence of the production unit, the coordination logic between devices, and the exception handling mechanism. The external system does not need to understand the specific interactions between the devices within the unit, but only needs to manage them through the interface of the unit controller.

5. The packaging method for digital twin virtual device modeling and production unit combination according to claim 4 is characterized in that: The hierarchical encapsulation in step 2 is as follows: A. Define a hierarchical packaging model structure: After combining the various production units, it is necessary to design a higher-level packaging model. B. Build a hierarchical interaction interface and coordination mechanism: At the production line level, it is necessary to design a unified hierarchical coordination control logic, that is, the production scheduling and coordination logic encapsulated within the production line model. This logic is used to organize the collaboration and information exchange of various production unit modules. C Multi-level abstraction and recursive encapsulation: The above method can be recursively extended to higher system levels.

6. The packaging method for digital twin virtual device modeling and production unit combination according to claim 5, characterized in that: A defines a hierarchical encapsulation model structure, as follows:

1. After completing the production unit level combination, build a production line level packaging model. The production line level packaging model corresponds to a complete production line entity, which is recorded as the ProductionLine class; 2. The ProductionLine class encapsulates several production unit modules as component submodules. Each production unit module is an encapsulation implemented by the WorkUnit class in the previous step. 3 The ProductionLine class maintains the following member variables: 3.1 Module Registry, used to dynamically store and manage metadata information of each sub-module, including module identification, function description, and input / output interface definition; 3.2 Ordered submodule list List <workunit> workUnits, which contains all production unit module instances in the order of process flow or functional partition;< / workunit> 4 The ProductionLine class only exposes the following unified production line interface: 4.1startLine()——Start the entire production line and trigger the startUnit() of each internal submodule in turn; 4.2stopLine()——Stop the entire production line and call stopUnit() of each submodule in reverse order to ensure safe shutdown; 4.3getLineStatus()——aggregates and returns the operating status and performance indicators of each sub-module, providing high-granularity feedback on the overall status of the production line; 5. The specific implementation details of the submodules are shielded within the ProductionLine class. When the above unified interface is called externally, the device-level entities within the submodules cannot be directly accessed or modified. The overall control and monitoring of the production line can only be completed through the startLine(), stopLine(), and getLineStatus() interfaces. 6 At a higher level, the production line-level packaging model can be used as a subcomponent of the Workshop or higher-level model, and recursively embedded through the same packaging and interface design principles to achieve multi-level abstraction and unified management.

7. The packaging method for digital twin virtual device modeling and production unit combination according to claim 5, characterized in that: B builds a hierarchical interactive interface and coordination mechanism. The specific construction of the hierarchical interactive interface and coordination mechanism is as follows:

1. Set up an information event bus within the ProductionLine class to implement command issuance and status reporting between production units. It supports synchronous control and asynchronous notification, and handles data format differences through the adaptation layer to ensure transparent communication between modules.

2. Establish module dependencies and schedule each submodule according to the process sequence. It supports multiple scheduling strategies to achieve unified control. When an exception occurs, the event bus triggers a linkage response, including linkage shutdown, backup path switching, degraded operation, or automatic retry, and dynamically processes and provides feedback based on the configuration.

3. Collect the running status of each module in a unified manner, provide overall status interface and event subscription, support real-time monitoring and historical tracing, Scheduling strategies and exception handling are dynamically adjusted through configuration files, supporting online updates and security permission control.

4. ProductionLine can be embedded as a subcomponent in higher-level models. ProductionLine can be embedded as a subcomponent in Workshop or higher-level models. The upper layer only manages it through high-granularity interfaces, without having to worry about the details of internal interactions. The same mechanism can be reused at higher levels, forming a complete hierarchical interaction and coordination system from the device level to the workshop level and even the factory level. Layered collaboration and abstract management are achieved through unified interfaces and event upload.

8. The packaging method for digital twin virtual device modeling and production unit combination according to claim 5, characterized in that: C multi-level abstraction and recursive encapsulation, as follows: 1 Define the workshop-level packaging model Workshop at a higher level, and manage multiple production line-level packaging models (ProductionLine) as submodules. 2Workshop only exposes the unified interface of the workshop level to the outside world, shielding the specific details of the lower-level production lines and units.

3. The workshop maintains the production line list and its metadata information, supports dynamic management and status aggregation, and realizes unified scheduling and monitoring of the production line.

4. The workshop-level model has abnormal coordination capabilities. When a production line fails, it can trigger a linkage shutdown or backup plan to ensure the continuity of the overall production. 5 According to the principle of recursive encapsulation, Workshop can be embedded as a submodule of a higher-level system, supporting multi-level and multi-level unified management and scheduling, achieving the goal of clear system abstraction levels and low coupling.

Images