A packaging method for digital twin virtual device modeling and production unit combination

Abstract

The application relates to a packaging method for digital twin virtual device modeling and production unit combination, which realizes modeling of a virtual device through a top-down abstraction process, and combines information hiding and a unified interface mechanism to ensure high-cohesion packaging of key attributes, states and behaviors of the virtual device; further, a production unit level combination and hierarchical packaging architecture is constructed based on the device model, and through unified workstation level, production line level and workshop level interfaces and scheduling logic, recursive combination and interoperation of multi-level modules are realized; the method clearly defines the modeling and packaging process of the digital twin virtual device, highlights the high-cohesion packaging and interface uniformity of the model, supports cross-level combination and scheduling logic design, thereby significantly improving the consistency and implementability of the model in the system integration, evolution expansion and module reuse process, and providing universal and standardized technical support for hierarchical construction and efficient deployment of virtual devices in intelligent manufacturing systems.

Description

Technical Field

[0001] This invention relates to a packaging method for modeling and assembling production units of digital twin virtual devices, belonging to the field of digital twin and virtual debugging technology. Background Technology

[0002] As the manufacturing industry transforms towards "intelligentization, digitalization, and flexibility," virtual commissioning of production units based on digital twins has become a key technological means to ensure the performance and reliability of next-generation intelligent manufacturing systems. Digital twin technology provides a simulation verification platform for the commissioning process by accurately replicating the structure, behavior, and interaction of physical equipment in virtual space. Virtual commissioning is an application of digital twins; by constructing a digital twin model of the equipment, design defects can be identified in advance through simulation verification in a virtual environment before implementation on the physical equipment. However, existing methods often present the internal state and control logic of the 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 in meeting the needs of large-scale, cross-level virtual commissioning. To address these issues, this invention proposes an encapsulation method for modeling and combining virtual equipment using digital twins. Through a top-down abstraction process, information hiding and unified interface mechanisms, and a multi-level encapsulation architecture, it achieves a modular, highly cohesive, and loosely coupled multi-level modeling system, providing an efficient, reusable, and easily maintainable solution for virtual commissioning of intelligent manufacturing systems. Summary of the Invention

[0003] This invention addresses the problems existing in the prior art by providing an encapsulation method for modeling and assembling production units of digital twin virtual devices. This method includes a top-down abstraction process, information hiding and unified interface mechanism, and a multi-level encapsulation architecture, realizing a modular, highly cohesive, and loosely coupled multi-level modeling system.

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

[0005] Step 1: Virtual device encapsulation modeling,

[0006] Step 2: Production unit-level assembly and hierarchical packaging;

[0007] or

[0008] Step 2: Hierarchical packaging and production unit-level assembly; In step 2 of this solution, the production unit-level assembly 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 typically follows a top-down abstraction process, with the main steps including:

[0010] A. Analyze the function and composition of the physical device. Systematically identify and analyze each component of the actual device, clarify the subsystems and their functions within the device, and define their dynamic characteristics and interaction relationships. This step is the foundation for virtual device encapsulation;

[0011] B. Determine the internal states and attributes. Based on the analysis results, define the internal state variables and key attributes of the virtual device model. These states and attributes must accurately reflect the operating status of the actual device under different working conditions;

[0012] C provides a unified interface design. It defines a clear and standardized input / output interface for the virtual device model, abstracts sensor data input and actuator control command output, and ensures that interactions between devices have a clear and standardized interface.

[0013] D encapsulates behavioral logic. Based on the device's functions and interfaces, the device's operational logic is encapsulated as methods or rules within a class. This logic is not visible to the outside world, and device state updates and function execution are achieved through unified interface calls.

[0014] Verification and Iterative Optimization: Verification is conducted using simulation platforms or by comparing data with actual equipment to ensure that the virtual equipment model behaves consistently with the actual equipment in terms of state updates and event feedback. Continuous optimization of model parameters and logic further improves model accuracy.

[0015] The encapsulation and modeling process for virtual devices requires the use of information hiding mechanisms and interface unification mechanisms.

[0016] Mechanism 1: The information hiding mechanism ensures that the content of the virtual device is not visible to the outside world, reducing the coupling between modules. This mechanism can hide the internal state, algorithm and control logic, and control the access permissions of the interface.

[0017] Mechanism 2: The unified interface 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 device models.

[0018] Production unit-level composition and hierarchical encapsulation, building upon virtual device encapsulation, further abstracts and combines components from the device level to the production unit level, and is a crucial part of digital twin system modeling. Specifically, it can include two methods: production unit-level composition and hierarchical encapsulation.

[0019] Step 2: Production cell-level assembly method

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

[0021] A. Define 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, 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 specific equipment details, ensuring that external systems can manage and call the production units in a unified and concise manner.

[0022] B. Define the internal device interaction relationships within the production unit: After defining the overall interface, it is necessary to design the calling relationships and data interaction methods within each virtual device; it is also necessary to construct the calling process and data transfer mechanism for inter-device collaboration to ensure that each device works collaboratively according to the predetermined process. Detailed descriptions of the triggering conditions, calling relationships, and data flow between devices are achieved through flowcharts and sequence diagrams to realize efficient and orderly internal interaction.

[0023] C. Establish production unit-level control logic: After completing the design of equipment 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 runtime sequence of the production unit, the coordination logic between equipment, and the exception handling mechanism. External systems do not need to understand the specific interactions between the devices within the unit, but only need to manage them through the interface of the unit controller.

[0024] Step 2: Hierarchical encapsulation method

[0025] In this scheme, the hierarchical encapsulation method, based on the completion of production unit assembly, further abstracts and combines multiple production unit-level encapsulation modules to a higher level, forming an abstract encapsulation structure at the production line or even workshop level, thus constituting a multi-level digital twin modeling system. Its implementation steps include defining a hierarchical encapsulation model structure, constructing hierarchical interaction interfaces and coordination mechanisms, 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 assembly, construct the production line-level encapsulation model, which corresponds to a complete production line entity, denoted as the ProductionLine class;

[0028] 2. The ProductionLine class described above encapsulates several production unit modules as component sub-modules. Each production unit module is an encapsulation body implemented by the WorkUnit class in the previous steps.

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

[0030] 3.1 ModuleRegistry is used to dynamically store and manage the metadata information of each submodule, including module identifier, function description, and input / output interface definition;

[0031] 3.2 Ordered Submodule List <workunit>workUnits, which are sequentially included according to the process flow or functional partitioning order.

[0032] There are examples of production unit modules;

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

[0034] 4.1 startLine() — Starts the entire production line, triggering startUnit() of each internal sub-module in sequence;

[0035] 4.2 stopLine() — Stops the entire production line, calling stopUnit() of each submodule in reverse order to ensure a safe shutdown;

[0036] 4.3 getLineStatus() — Aggregates and returns the running status and performance indicators of each submodule, providing a high-granular overall production line status.

[0037] State feedback;

[0038] The ProductionLine class described in 5 hides the specific implementation details of the sub-modules. When the above unified interface is called from the outside, the device-level entities inside the sub-modules must not be directly accessed or modified. The overall control and monitoring of the production line can only be completed through the three interfaces startLine(), stopLine(), and getLineStatus().

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

[0040] B. Constructing a Hierarchical Interaction Interface and Coordination Mechanism: At the production line level, a unified hierarchical coordination and control logic needs to be designed, i.e., production scheduling and coordination logic encapsulated within the production line model. This logic is used to organize the collaboration and information interaction among various production unit modules, such as the data and event exchange relationships between upstream and downstream units. It also includes cross-unit coordination mechanisms in abnormal or emergency situations, such as the coordinated shutdown of the entire production line or the triggering of backup plans when a unit fails.

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

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

[0043] 2. Establish module dependencies and schedule each submodule according to the process flow sequence, supporting multiple scheduling strategies to achieve unified control. When an anomaly 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.

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

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

[0046] 4. ProductionLine can be embedded as a sub-component into a higher-level model. ProductionLine can be embedded as a sub-component into Workshop or a higher-level model, and the higher level can do so only through high-granularity interfaces (such as startWorkshop(), getWorkshopStatus()).

[0047] Management is straightforward, eliminating the need to concern oneself with internal interaction details. 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 a unified interface and event uploading.

[0048] C Multilevel Abstraction and Recursive Encapsulation:

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

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

[0051] 2. Workshop only exposes a unified workshop-level interface, such as startWorkshop(), stopWorkshop(), and getWorkshopStatus(), shielding the specific details of the underlying production line and unit.

[0052] Workshop 3 maintains a list of production lines and their metadata, supporting dynamic management and status aggregation to achieve unified scheduling and monitoring of production lines.

[0053] 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. Following the principle of recursive encapsulation, Workshop can be embedded as a submodule of a higher-level system, supporting multi-level and multi-layered unified management and scheduling, and achieving the goal of clear system abstraction and low coupling.

[0055] This recursive encapsulation method makes the system's abstraction level clear, which is convenient for high-level planning, scheduling and management, without having to delve into low-level details.

[0056] An encapsulation method for modeling and assembling production units of digital twin virtual devices provides an efficient and reusable modeling approach for virtual debugging systems. This method encapsulates virtual devices by encapsulating key attributes, states, and behaviors within a single class, providing standardized input / output interfaces. Subsequently, a production unit-level assembly model is built upon the device model, further extending to a multi-layered encapsulation system to form a complete digital twin modeling structure from device to production line to workshop. This method not only simplifies the conversion process from physical devices to virtual models and improves modeling efficiency, but also significantly reduces coupling between models through strict information hiding and interface unification mechanisms, avoiding errors in repetitive modeling and manual integration.

[0057] Compared with existing technologies, this invention has the following significant advantages: The encapsulation method for modeling and assembling production units of digital twin virtual devices enables top-down modular modeling of virtual devices, followed by the combination and encapsulation of production units and higher-level components, resulting in a clearly structured, multi-layered digital twin virtual device model. The introduction of information hiding and a unified interface mechanism ensures low coupling and plug-and-play functionality between modules, while also supporting the shielding and reuse of implementation details from the upper-layer model. Simultaneously, verification and iterative optimization through comparison with simulation platforms or actual device data ensure consistency between the virtual device model and actual device behavior in terms of state updates and event feedback. Continuous optimization of model parameters and logic improves model accuracy, effectively enhancing the accuracy of the virtual device model and system reliability. This significantly improves modeling efficiency and reduces subsequent maintenance costs, providing solid technical support for the rapid deployment and expansion of large-scale digital twin systems. Attached Figure Description

[0058] Figure 1 This is 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 production line hierarchical packaging of the present invention. Detailed Implementation

[0061] To enhance understanding of the present invention, the embodiments will be described in detail below with reference to the accompanying drawings.

[0062] Example:

[0063] Figure 1 As shown, 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 clamp;

[0065] B determines the internal state and attributes, and abstracts the core states of the riveting machine, such as real-time pressure value and real-time displacement value, as well as the core functions such as starting riveting and cylinder propulsion.

[0066] The C design uses a unified interface to map the above functional elements to a virtual device class called RivetMachine. The pressure and displacement properties are set to private for internal state management, while the initiateClamp() and releaseClamp() methods are set to public to provide control capabilities to the outside world as a unified interface.

[0067] D encapsulates the behavioral logic, and the logic for updating the state after detecting that the pressure and position have reached the predetermined values ​​is written inside startRivet();

[0068] E-verification and iterative optimization involve comparing the data from the virtual simulation platform with the test data from the actual equipment to continuously optimize the accuracy of the virtual model.

[0069] Among them, the encapsulation modeling method of virtual devices encapsulates the key attributes, states and behaviors of the device in independent classes, and achieves modularity, high cohesion and low coupling through information hiding and unified interface mechanisms. It relies on a top-down abstraction 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, it ensures the model's accurate mapping of the dynamic characteristics of physical devices and its maintainability.

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

[0071] Mechanism 1: The information hiding mechanism ensures that the content of the virtual device is not visible to the outside world, reducing the coupling between modules. This mechanism can hide the internal state, algorithm and control logic, and control the access permissions of the interface. In the above embodiment, internal state attributes such as pressure and displacement and specific behavioral logic are set to private, and limited access is provided to the outside world only through controlled interfaces, so as to shield the implementation details and reduce module coupling.

[0072] Mechanism Two: The unified interface mechanism, through standardized device interaction protocols, enables different modules of the system to communicate and collaborate in a consistent and compatible manner. This mechanism improves the convenience of virtual device integration and the scalability of the system, achieving plug-and-play functionality for the device model. The above embodiment defines public methods such as `initateClamp()`, `releaseClamp()`, and `startRivet()` for the riveting machine virtual device, ensuring that external systems can interact with the device using consistent semantics and calling methods, achieving plug-and-play functionality and high scalability.

[0073] Building upon the aforementioned virtual device encapsulation of the riveting machine, further abstract encapsulation and combination from the equipment level to the production unit level are achieved, namely, production unit-level combination and hierarchical encapsulation. Specifically, this can include two methods: production unit-level combination and hierarchical encapsulation.

[0074] Step 2: Production cell-level assembly method

[0075] Figure 2 As shown, the following explicit modeling process should be followed during the assembly of production units of the riveting machine:

[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 need to implement. In the riveting station, the functional boundary of the unit is clearly defined as the "riveting task." The combination model should expose a unified start / stop operation interface (startWorkUnit(), stopWorkUnit()) and a status query interface (getUnitStatus()). The interfaces defined at this stage are different from the underlying device interfaces, focusing more on the abstraction of the overall function of the entire unit rather than the functional details of individual devices.

[0077] B. Clarify the internal equipment interaction relationships within the production unit: After defining the overall interface, it is necessary to design the calling relationships and data interaction methods within each virtual device. In the riveting station, the fixture controller is responsible for workpiece positioning and clamping, the riveting machine completes the riveting operation, and the conveying mechanism is responsible for loading, unloading, and transferring workpieces. These devices collaborate through a clearly defined interface calling sequence and data interaction. Therefore, a clear device calling flowchart and sequence diagram should be designed to clarify the calling order, conditions, and data interaction methods between each device.

[0078] C. Establishing Production Unit-Level Control Logic: After completing the design of equipment interaction relationships, the production unit-level control logic needs to be encapsulated within the unit. In the riveting station, WorkUnitController achieves a simple interaction by exposing only three interfaces: startWorkUnit(), stopWorkUnit(), and getUnitStatus(), through unified management of the three sub-modules: fixture controller, riveting machine, and conveying mechanism. Internally, startWorkUnit() sequentially calls FixtureController.positionWorkpiece() to complete workpiece positioning, RivetMachine.startRivet() to execute pressing, and Conveyor.startTransfer() to transport the workpiece, while performing readiness checks at each step through status feedback to ensure seamless process continuity. stopWorkUnit() issues stop commands in reverse order, and getUnitStatus() summarizes the status of each sub-module and returns the overall running results and fault information, thus realizing the timing arrangement, status coordination, and unified monitoring of the production unit.

[0079] Step 2: Hierarchical encapsulation 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: In Figure 3 In the workshop-level model shown, a hierarchical encapsulation model structure is first defined to encapsulate specific production lines and their workstations into the workshop-level framework. Taking production line A as an example, the corresponding ProductionLineA class is constructed:

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

[0083] 2ProductionLineA internally maintains the ModuleRegistry, which records the identifiers, functional descriptions, and input / output interface definitions for assembly stations, inspection stations, packaging stations, etc.; it also maintains an ordered list of sub-modules, workUnits, arranged sequentially according to the process flow, and serves as the basis for start-up, stop, and status aggregation.

[0084] 3ProductionLineA exposes only a unified interface to the outside world:

[0085] startLine(): Triggers startUnit() for each workstation sequentially according to the order of assembly → inspection → packaging or a parallel strategy;

[0086] stopLine(): Calls stopUnit() in reverse order for each workstation to ensure that all workpieces are safely stopped or unloaded.

[0087] getLineStatus(): Aggregates the operating status, capacity indicators and fault information of each workstation, and provides overall feedback for the production line;

[0088] 4ProductionLineA internally shields the specific equipment details of each workstation. The upper level or external parties can only control and monitor the entire production line through the above interface, avoiding dependence on the internal implementation of the assembly mechanism, testing system or packaging device.

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

[0090] B builds a hierarchical interaction interface and coordination mechanism within ProductionLineA to organize collaboration and exception handling between workstations:

[0091] 1. Lightweight information / event bus is used to transmit start, stop, status reporting and other messages between assembly station, inspection station and packaging station; the adapter layer can convert the data format or unit of different stations when needed to ensure transparent communication;

[0092] 2. Establish workstation dependencies, and have the scheduling engine call the startup interface of each workstation in this order or in parallel, and support priority or parallel processing when needed;

[0093] 3 When an anomaly occurs at a workstation, the event bus immediately reports it to ProductionLineA. The pre-configured strategy determines whether to stop subsequent workstations in reverse order, switch to a backup workstation or adjust the process, retry or pause and notify operations and maintenance. The processing result is fed back through a unified status interface.

[0094] 4. Periodically or when triggered by events, each workstation reports key operating indicators. After being aggregated by getLineStatus(), a real-time overview is provided to the workshop-level or monitoring system. Scheduling strategies and exception handling rules are maintained through 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 manage multiple production lines in a unified manner without needing to understand the internal interaction details between each workstation. This mechanism can be reused at higher levels to form a complete interaction and coordination system from equipment level to workstation level to production line level to workshop level and even factory level.

[0096] C Multilevel Abstraction and Recursive Encapsulation: Multilevel abstraction and recursive encapsulation in a Workshop-level Model:

[0097] 1. ProductionLineA, ProductionLineB, etc. are managed as sub-components. Workshop only exposes interfaces such as startWorkshop(), stopWorkshop(), and getWorkshopStatus() to the outside world, and hides the specific details of each production line and its workstation.

[0098] Workshop 2 maintains the registry and list of each production line, supporting dynamic start-up and shutdown, status aggregation and cross-production line scheduling; when a production line fails, Workshop can perform cross-production line coordinated shutdown or resource reallocation according to preset strategies to ensure overall production continuity.

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

[0100] In summary, by adopting an object-oriented encapsulation modeling method for the riveting machine station and its production line, key states and behavioral logic are cohesively encapsulated in the RivetMachine class. By utilizing information hiding and interface unification mechanisms, multi-level encapsulation and recursive combination of virtual equipment, production units, production lines, and workshops are completed, 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. Equivalent transformations or substitutions made based on the above technical solutions all fall within the scope of protection of the claims of the present invention.< / workunit>

Claims

1. A packaging method for modeling and assembling production units of digital twin virtual devices, characterized in that, The method includes the following steps: Step 1: Virtual device encapsulation modeling, Step 2: Production unit-level assembly and hierarchical packaging; In step 1, the encapsulation modeling of the virtual device class follows a top-down abstraction process, and the main steps include: A. Analyze the functions and composition of physical equipment, systematically identify and analyze each component of the actual equipment, clarify the functions and roles of each subsystem within the equipment, and define their dynamic characteristics and interaction relationships. This step is the foundation for virtual equipment encapsulation. B. Determine the internal state and attributes. Based on the analysis results, define the internal state variables and key attributes of the virtual device model. These states and attributes must be able to accurately reflect the operating status of the actual device under different working conditions. The C design provides a unified interface, clearly defining a unified input and output interface for the virtual device model, abstracting sensor data input and actuator control command output, and ensuring that the interaction between devices has a clear and standardized interface. D encapsulates behavioral logic. Based on the device's functions and interfaces, it encapsulates the device's operational logic into class methods or rules. This logic is not visible to the outside world. The device's state updates and function execution are achieved through unified interface calls. Verification and iterative optimization are carried out using simulation platforms or by comparing data with actual equipment to ensure that the virtual equipment model is consistent with the behavior of the actual equipment in terms of state updates and event feedback, and to continuously optimize model parameters and logic to improve model accuracy. In step 2, the production unit-level assembly 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. Define the internal device interaction relationships within the production unit: After defining the overall interface, it is necessary to design the calling relationships and data interaction methods within each virtual device. C. Establish production unit-level control logic: After completing the design of equipment interaction relationships, the production unit-level control logic needs to be encapsulated inside the unit. This control logic is implemented through an internal management class. The encapsulated production unit's overall runtime sequence, equipment coordination logic, and exception handling mechanism are all handled by the external system. The external system does not need to know the specific interactions between the devices inside the unit, but only needs to manage them through the interface of the unit controller. The hierarchical encapsulation in step 2 is as follows: A. Define a hierarchical encapsulation model structure: After combining the various production units, it is necessary to design a higher-level encapsulation model, as follows:

1. After completing the production unit-level combination, construct a production line-level encapsulation model, which corresponds to a complete production line entity, denoted as the ProductionLine class.

2. The ProductionLine class described above encapsulates several production unit modules as component sub-modules. Each production unit module is an encapsulation body implemented by the WorkUnit class in the previous steps.

3. The ProductionLine class internally maintains the following member variables: 3.1 ModuleRegistry, used to dynamically store and manage metadata information of each submodule, including module identifier, function description, and input / output interface definition; 3.2 List of ordered submodules <workunit> workUnits contains all production unit module instances in the order of process flow or functional partitioning.< / workunit> The ProductionLine class described in section 4 exposes only the following unified production line interfaces: 4.1 startLine() – Starts the entire production line, triggering startUnit() of each internal sub-module in sequence; 4.2 stopLine() – Stops the entire production line, calling stopUnit() of each sub-module in reverse order to ensure safe shutdown; 4.3 getLineStatus() – Aggregates and returns the running status and performance indicators of each sub-module, providing high-granularity feedback on the overall status of the production line. The ProductionLine class described in 5 hides the specific implementation details of the submodules. When the startLine(), stopLine(), and getLineStatus() interfaces are called from the outside, the device-level entities inside 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 encapsulation model can be used as a sub-component of the Workshop-level or higher-level model, and can be recursively embedded through the same encapsulation and interface design principles to achieve multi-level abstraction and unified management. B. Constructing a Hierarchical Interaction Interface and Coordination Mechanism: At the production line level, a unified hierarchical coordination and control logic needs to be designed, namely, production scheduling and coordination logic encapsulated within the production line model. This logic is used to organize the collaboration and information exchange among various production unit modules, specifically constructed as follows:

1. An information event bus is set up inside the ProductionLine class to enable command issuance and status reporting between production units, supporting synchronous control and asynchronous notification. An adaptation layer handles data format differences, ensuring transparent communication between modules.

2. Establish module dependencies, schedule sub-modules according to the process flow sequence, support multiple scheduling strategies, achieve unified control, and trigger a linkage response via the event bus when an anomaly occurs, including linkage shutdown, backup path switching, degraded operation, or automatic retry, and dynamically process and provide feedback based on configuration.

3. Unified collection of the operational status of each module, providing an overall status interface and event subscription, supporting real-time monitoring and historical tracing, dynamic adjustment of scheduling strategies and exception handling through configuration files, supporting online updates and security access control.

4. ProductionLine can be embedded as a sub-component into a higher-level model. ProductionLine can be embedded as a sub-component into Workshop or a higher-level model. The upper level only manages through a high-granularity interface and does not need to care about the internal interaction details. The same mechanism can be reused at a higher level to form a complete hierarchical interaction and coordination system from the equipment level to the workshop level and even the factory level. Layered collaboration and abstract management are achieved through a unified interface and event upload. C multi-level abstraction and recursive encapsulation: allows for recursive expansion to higher system levels; specifically as follows:

1. Define a workshop-level packaging model at a higher level, and manage multiple production line-level packaging models (ProductionLine) as sub-modules in a unified manner.

2. Workshop only exposes a unified workshop-level interface, shielding the specific details of the underlying production lines and units.

3. The workshop maintains a list of production lines and their metadata, supporting dynamic management and status aggregation to achieve unified scheduling and monitoring of the production lines. The workshop-level model has the ability to coordinate in case of an anomaly. When a production line fails, it can trigger a coordinated shutdown or a backup plan to ensure the continuity of overall production.

5. Following the principle of recursive encapsulation, Workshop can be embedded as a submodule of a higher-level system, supporting multi-level and multi-layered unified management and scheduling, and achieving the goal of clear system abstraction and low coupling.

2. The packaging method for modeling and assembling production units of digital twin virtual devices according to claim 1, characterized in that, in, The encapsulation and modeling process for virtual devices requires the use of information hiding mechanisms and interface unification mechanisms. Mechanism 1: The information hiding mechanism ensures that the content of the virtual device is not visible to the outside world, reducing the coupling between modules. This mechanism hides the internal state, algorithm and control logic, and controls the access permissions of the interface. Mechanism 2: The unified interface mechanism enables different modules of the system to communicate and collaborate in a consistent and compatible manner through standardized device interaction protocols. This mechanism improves the convenience of virtual device integration and the scalability of the system, and enables plug-and-play device models.

Images