Hierarchical concurrent state transition network method for digital twin virtual debugging

Abstract

The invention relates to a hierarchical concurrent state transition network method for digital twinning virtual debugging. Main principles, structures and main construction processes of a mechanism of the method are listed. According to the method, hierarchical abstract management of a macroscopic process and microscopic execution details is achieved through a composite state and subnet mechanism, dynamic linkage and synchronous interlocking between concurrent components are achieved through a global event release-response and cross-subnet state dependency mechanism, and mutual exclusion access and release of shared resources are completed in combination with a global resource token mechanism. On the basis, a visual and verifiable concurrent process model can be generated in a virtual debugging environment, and deadlock detection and resource bottleneck analysis are supported, so that the accuracy, reliability and maintainability of digital twin virtual debugging of a complex production unit or a software system are remarkably improved.

Description

Technical Field

[0001] The present invention specifically relates to a logic deduction method in a virtual debugging process, specifically to a hierarchical concurrent state transition network (HCSTN) method for digital twin virtual debugging, which is particularly suitable for debugging logic deduction in multi-device collaboration and high-concurrency scenarios, and belongs to the 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 means of ensuring the performance and reliability of next-generation intelligent manufacturing systems. Digital twin technology accurately replicates the structure, behavior, and interactions of physical equipment in virtual space, providing a simulation and verification platform for commissioning processes. However, with the surge in the number of production unit devices, the increasing degree of process coupling, and the enhanced level of concurrent collaboration, traditional virtual commissioning methods are struggling to meet the following requirements:

[0003] (1) Complexity of debugging logic and multi-constrained concurrency: In actual production processes, devices face strict startup sequences, synchronization constraints, resource competition and mutual exclusion, timeout responses, and other multi-dimensional timing requirements. Traditional methods based on manual experience or simple finite state machines (FSMs) are difficult to formally and comprehensively describe and verify these complex constraints. Once the timing logic or resource allocation logic of any step in the process is flawed, it may lead to distorted simulation results, resulting in safety risks or performance bottlenecks during the physical debugging phase.

[0004] (2) Insufficient formal verification capabilities: Although commonly used offline simulation or graphical state transition diagrams (STDs) have a high degree of visualization, they have natural limitations in concurrent execution and resource management: the conditional linkage and synchronization between a large number of parallel sub-processes are difficult to express intuitively, and resource occupation and release are not included in the formal model, resulting in risks such as deadlock, competition and starvation being difficult to discover and locate in a timely manner, and simulation verification efficiency is low and coverage is limited.

[0005] (3) Resource contention and deadlock risk: In modern production units, multiple devices, such as servo motors, pneumatic-hydraulic booster cylinders, and AGVs, often share the same transmission channel, fixture, or power source. In virtual debugging models that lack a unified resource coordination mechanism, each submodule's use and release of shared resources can only be hard-coded in the form of "variable flags" or "extra branches." This is neither intuitive nor conducive to formal analysis, making it difficult to pre-detect potential deadlocks and performance bottlenecks.

[0006] In summary, the current digital twin-driven virtual debugging technology still lacks a unified modeling and verification method that can simultaneously meet the three major requirements of "formal expression of multi-constraint timing logic, graphical visualization of concurrent behaviors, global resource coordination and deadlock detection". It is urgent to develop a new formal framework to improve the rigor, reliability and scalability of virtual debugging of complex production units. Summary of the Invention

[0007] In order to solve the problem of insufficient modeling of concurrent behaviors and resource competition in the virtual debugging process in the existing technology, the present invention proposes a hierarchical concurrent state migration network method for digital twin virtual debugging. This method describes the concurrency and resource constraints of each sub-process in a formal way, adopts hierarchical abstraction to manage the system state at multiple levels, and realizes dynamic linkage between subnets through event broadcasting and conditional dependencies. At the same time, a global resource token mechanism is used to complete the mutual exclusive access and release of shared resources. With the help of the HCSTN model, a visual and verifiable virtual debugging process can be generated, and deadlock detection and resource bottleneck analysis can be supported. The technical solution of the present invention is as follows:

[0008] (1) Layered abstraction mechanism;

[0009] (2) Dynamic linkage mechanism;

[0010] (3) Global resource coordination mechanism;

[0011] (4) HCSTN formal model.

[0012] HCSTN's layered abstraction mechanism organizes states or subnetworks hierarchically, expanding from the top to the bottom, breaking down complex systems into sub-models of varying granularity. Each layer focuses on specific functionality, with higher layers responsible for scheduling and lower layers providing execution details, maintaining clear boundaries and interfaces between layers. This structure ensures semantic consistency while improving model readability and ease of maintenance.

[0013] The principle and structure of the hierarchical abstraction mechanism of HCSTN are mainly:

[0014] HCSTN achieves hierarchical abstraction by combining composite states with subnets. The model contains both indecomposable atomic states and composite states within which subnets can be nested. The latter appears externally as a single high-level node, while internally, subnets are used to depict finer-grained dynamic behavior. When the system enters a composite state, its corresponding subnet is activated; when the system leaves it, the subnet is deactivated. By using the overall network as the root node, composite states as intermediate nodes, and atomic states as leaf nodes in a hierarchical tree structure, and supporting the folding and unfolding of subnets, multi-level visualization and management, from top-level processes to bottom-level execution details, can be achieved while maintaining model semantic consistency.

[0015] For example, Figure 1 The figure shows a two-layer HCSTN network. Its top-level state container network contains an atomic state C and two composite states A and B. The structure of composite state B (consisting of substates S1, S2, S3, S4, S5 and their transitions) is shown on the right. When the system is in composite state B, it means that subnet B_detail is active; when leaving B, execution within the subnet terminates accordingly.

[0016] In order to ensure the mutual exclusion and completeness of the composite state and other global state sets, the formula is further introduced:

[0017] Formula (1) Hierarchical abstract independence constraint:

[0018] Let S be the global state set, is the set of all composite states; for each composite state s∈Composite, let the set of internal states of its subnet be Subs(s). Then it must satisfy mutual exclusion and completeness:

[0019]

[0020] The first formula ensures that the subnet state belongs to the global state set, and the second formula ensures that the internal state of the subnet is mutually exclusive with the external state.

[0021] Before modeling the hierarchical subnet, the system formalized key timing constraints based on linear temporal logic (LTL) and mapped these constraints into executable node and edge conditions using traditional state transition diagrams (STDs). Since this paper focuses on expanding the existing STD model into a hierarchical and concurrent HCSTN, the following will omit the details of LTL and STD construction and focus directly on the generation and organization of hierarchical state transition diagrams. The specific process of hierarchical subnet modeling is as follows:

[0022] 11) Top-level status and subnet division:

[0023] a) Starting from the overall business process, extract the top-level key state nodes and construct the top-level state transition diagram;

[0024] b) Divide the system into several underlying subnets according to functions or actuators, each subnet corresponding to a physical sub-process or device action;

[0025] c) Clarify the activation / deactivation relationship between the top layer and each subnet: The top layer state transition determines when to activate which subnet, and the subnet completion status in turn drives the next step of the top layer.

[0026] 12) Extracting atomic states and events within the subnet:

[0027] a) For each underlying subnet, sort out the atomic states involved in the subnet and the corresponding state transition conditions;

[0028] b) Extract the events or signals required to trigger migration within the subnet (such as sensor feedback, timer timeout, action completion signal, etc.) to prepare for the subsequent definition of migration trigger conditions and resource requests within the subnet;

[0029] c) Define the initial / end nodes for each subnet: that is, which atomic state to start from when entering the subnet, and what completion flag to return or issue after execution.

[0030] 13) Define the state transition structure within the subnet:

[0031] a) Based on the extracted atomic states and events, a detailed state transition diagram is drawn for each subnet, including: state nodes (atomic states) and their behavioral semantics, transition edges and their departure conditions, and resource request or release annotations;

[0032] b) For each transition, specify the source and target states, trigger conditions (events, state dependencies, timeouts, etc.), and accompanying event outputs (events to notify the top level or other subnets after the subnet is completed).

[0033] 14) Establish linkage between the top layer and subnets:

[0034] a) Map the “completion flag” of each subnet to the trigger event of top-level migration;

[0035] b) Add a trigger precondition to the top-level migration, requiring the corresponding subnet's completion event to exist (or the subnet to have exited to the specified state);

[0036] c) In the startup migration of the subnet, add "top-level status is in place" or "top-level event is received" as a trigger precondition to ensure that the subnet is activated only when the top-level enters the corresponding stage.

[0037] 15) Integrate to form a complete HCSTN hierarchy:

[0038] a) In the overall HCSTN model, the nodes and edges of the top-level state transition graph are first retained;

[0039] b) Insert each subnet into the corresponding composite state (the composite state contains the complete STD of the corresponding subnet);

[0040] c) Define the entry / exit mechanism of the composite state: upon entry, activate the initial state in the subnet; upon exit, wait for the subnet to enter the end state and emit a completion event;

[0041] d) Establish resource tokens and event broadcast channels between the top layer and the subnet to ensure that the two are executed in coordination and meet resource mutual exclusion requirements.

[0042] Through the above five main steps, we have completed the hierarchical abstraction of "top-level process → bottom-level subnet", refined the states and events within the subnet, and realized the dynamic linkage between the top level and the subnet through event broadcasting and triggering preconditions, ultimately forming a hierarchical, modular and verifiable HCSTN model.

[0043] HCSTN's dynamic linkage mechanism introduces event broadcasting, condition monitoring, and synchronization constraints into the model, enabling different sub-models to interact at runtime based on current state combinations or shared events. Whether it is a one-way trigger or the synchronization of multiple concurrent paths, it can be expressed in the same way, greatly simplifying the design of concurrent interactions.

[0044] The principle and structure of the HCSTN dynamic linkage mechanism are mainly:

[0045] The dynamic linkage mechanism in HCSTN consists of two parts: First, a global event publishing and response system is introduced: when a migration occurs, it can be accompanied by an event identifier. Other migrations declare their sensitivity to this event in their triggering conditions. When a migration generates an event, it is immediately broadcast to the HCSTN global network, and all migrations awaiting the event are synchronously activated and conditional checks are performed. Second, in terms of condition / state dependencies, migration trigger conditions can be referenced across subnets. That is, a migration within one subnet can directly use the state of another subnet as a triggering condition, thus explicitly specifying in the model which state combinations should trigger the linkage transition. Combined with the use of the event mechanism, a variety of complex concurrent interaction patterns can be expressed.

[0046] When inter-subnet linkage needs to satisfy both "cross-subnet events" and "local conditions", it can be formalized as follows:

[0047] Formula (2) Cross-subnet dynamic linkage triggering:

[0048] For migration t in subnet A A , if it depends on the completion event e from subnet B B→A And must meet its local conditions C A , then its migration trigger condition Guard(t A ) is defined as:

[0049] Guard(t A )=(received(e B →A))∧C A (3)

[0050] In addition, HCSTN also provides the concept of synchronous migration: when multiple migrations need to be executed strictly synchronously, they can be marked as the same synchronization group or a common synchronization event can be set to ensure that these migrations are either triggered at the same time or not triggered at all.

[0051] For example, as shown in Fig. 1, two parallel lines each have a transition T1 and T2, and it is desired that they occur simultaneously (either both or neither). In this case, T1 and T2 can be combined into a complex transition with two source states and two target states in the HCSTN, or a common synchronization event can be set for them to trigger together at the same logical time. Figure 2

[0052] The specific process for constructing the dynamic linkage mechanism is as follows:

[0053] 21) Identify concurrent subnets and linkage requirements:

[0054] a) Determine the concurrent subnets in the model that need to cooperate or interlock with each other, and clarify the action sequence or mutual exclusion relationship between them;

[0055] b) For each pair of subnets that need to be linked, list the trigger conditions (when one subnet is completed, the other subnet needs to be notified) and the corresponding inhibition conditions (when one subnet is in progress, the other subnet needs to be locked).

[0056] 22) Define the global event publishing-response mechanism:

[0057] a) In the HCSTN, specify event outputs (such as completion flags, exception flags, etc.) for key transitions, which are used to notify other subnets;

[0058] b) Declare sensitivity to the event ("receive event E") in the trigger condition of the target subnet's transition, to ensure simultaneous activation within the same macro-step;

[0059] c) When a certain transition condition is triggered, immediately broadcast the corresponding event to the global, and all transitions in the trigger that are waiting for the event will perform availability checks in parallel.

[0060] 23) Establish cross-subnet condition / state dependencies:

[0061] a) Reference the active state of Subnet B in the trigger precondition of Subnet A's transition, and vice versa, to form explicit cross-subnet dependencies;

[0062] b) Include "Subnet B is in state s" and "receive event E" in the trigger premise of a certain transition in Subnet A, to achieve "only trigger when other subnets meet certain states and events" static linkage;

[0063] 24) Configure resource mutual exclusion or complementary positions:

[0064] ​a) If two or more subnets need to mutually exclusive occupy the same resource during an action, a global mutually exclusive shared resource (Place) is created for the resource in the HCSTN, which contains the corresponding mutually exclusive token (Token);

[0065] b) Declare a request (Req) for the exclusive position token on the key migration of the relevant subnet, automatically blocking similar migrations of other subnets after taking it; return the token by releasing (Rel) when the action is completed;

[0066] c) Mutual exclusion and linkage suppression during the action are achieved through the occupation / release of resource tokens.

[0067] 25) Define the synchronous migration group:

[0068] a) For multiple transitions that need to be triggered strictly synchronously (multiple transitions fire together), mark them as the same synchronization group;

[0069] b) Alternatively, combine these migrations into a composite migration, set unified multi-source and multi-target states, and ensure that either they are triggered simultaneously or not at all;

[0070] c) Bind the same synchronization event or cross-subnet state prerequisite to all synchronization migration trigger preconditions to maintain the atomicity of the action;

[0071] Through the above five steps, we have achieved a systematic description of the triggering and inhibition relationship between concurrent subnets, established a global event publishing-response and cross-subnet state dependency mechanism, and ensured the interlocking and atomic execution of each subnet's actions through mutually exclusive resource locations and synchronous migration groups.

[0072] HCSTN achieves unified management of resource allocation and state transitions by incorporating shared resources into global formal semantics: A global place is created for each shared resource in the model, with tokens representing available capacity. Each migration specifies the required resource quantity before triggering, and returns the corresponding token upon completion or an exception. When triggering a migration, global token availability is checked, deducted after occupation, and returned upon completion or an exception. When multiple migrations compete for the same resource and tokens are insufficient, mutually exclusive scheduling is performed according to a pre-set policy. This mechanism is compatible with the hierarchical structure and event-driven nature of HCSTN, and supports deadlock and resource conflict detection based on formal analysis. This allows for intuitive and reliable characterization of concurrent resource contention scenarios, improving the model's practical applicability and security.

[0073] The main principles and structure of the HCSTN global resource coordination mechanism are as follows:

[0074] In HCSTN, the uniform management of resource allocation and state transition is achieved by including shared resources into a globally visible resource set R and representing their available capacities in the form of tokens: each transition declares the number of tokens it requires for occupation and release when defined; in the execution phase, the system first checks the global available amount of tokens for the corresponding resource, deducts the tokens and allows the transition if satisfied, otherwise blocks; tokens are returned when a transition ends or enters an exceptional branch, ensuring mutual exclusion among concurrent subnets; when multiple transitions compete for the same resource and the available tokens are insufficient, the execution is selected according to the pre-set conflict resolution strategy, and the remaining transitions enter the waiting state. The resource occupation state is regarded as part of the system configuration, and based on this mechanism, potential deadlocks and resource competition can be detected through formal analysis, thereby ensuring the correctness and safety of resource scheduling in dynamic operation.

[0075] For example, the attached Figure 3 Figure 1 shows a HCSTN model, where there is a global resource R (initially with 1 unit), subtask 1 moves from state X to state Y via transition T1, which requires the acquisition of resource R; subtask 2 moves from state U to state V via transition T2, which also requires the acquisition of R. The solid arrows represent state transitions, and the dashed arrows represent resource occupation and release relationships. Before triggering, transitions T1 and T2 will check whether resource R is available, and if so, it will be occupied (reducing the available amount of R to 0). Since R has only 1 unit, T1 and T2 cannot be executed simultaneously: if one of them executes and occupies R, the other must wait until the resource is released. Subsequently, when T1 or T2 completes execution, it will release R (restoring the available amount of R to 1), thereby awakening the other waiting transition. In this way, the HCSTN model ensures mutual exclusion of concurrent tasks for shared resources, avoiding conflicts.

[0076] The specific process for constructing the global resource coordination mechanism is as follows:

[0077] 31) Identify shared resources and mutual exclusion requirements:

[0078] a) Determine all global resources that concurrent subnets need to compete for in the system, and specify which subnets should maintain mutual exclusion for access to the same resource.

[0079] 32) Define resource library and token initialization:

[0080] a) For each shared resource r (r ∈ R) in the HCSTN model, create a corresponding shared resource library (Place), and place the corresponding number of tokens (Token) in the library according to the capacity of the resource.

[0081] 33) Extend the mapping of transition requests and release:

[0082] a) Add the following to the definition of each transition t:

[0083] Request set Req(t): indicates the resources and token count required before triggering;

[0084] Release set Rel(t): indicates the resources and their token numbers that need to be returned after triggering.

[0085] b) Include "subnet B is in state s" and "receives event E" as trigger conditions for a migration in subnet A, implementing a static linkage mechanism where the migration is triggered only when other subnets meet specific states and events.

[0086] 34) Resource enablement determination and conflict resolution:

[0087] a) When determining whether a transition t can be triggered, simultaneously check that its state / event conditions and all (r,n)∈Req(t) satisfy Cnt(r)≥n. If multiple transitions compete for the same resource and insufficient tokens are available, one transition is selected based on a preset priority or non-deterministic policy to occupy the token, and the others are re-evaluated in the next macro step.

[0088] b) To strictly characterize resource request and enable determination, we further introduce the formula:

[0089] Formula (3) Global resource enabling and conflict determination:

[0090] Let cnt(r) be the current number of available tokens for resource r, and Req(t) be the request mapping (multiset) of migration t to the resource.

[0091] A migration t is enabled in a configuration (M,cnt) if and only if:

[0092]

[0093] Guard(t) also contains state / event preconditions; when multiple migrations compete concurrently and ∑Req i When (r)>cnt(r), a token is selected according to the priority or non-deterministic strategy to be occupied first, and the next round of judgment is triggered by the release action after occupation.

[0094] 35) Migration execution and token synchronization update:

[0095] a) When the migration starts executing, the corresponding token is deducted from the global resource map Cnt according to Req(t).

[0096] The above five steps jointly complete the definition of the global resource repository, migration and resource mapping extension, enablement determination and conflict handling, as well as token occupation and release during the migration execution process, thereby realizing unified coordination and mutually exclusive access to shared resources in the HCSTN model.

[0097] 41) In order to more rigorously characterize HCSTN, a formal mathematical model can be established for it. An HCSTN model can be defined as a nine-tuple:

[0098] H=(S,T,E,R,F S ,F T ,Req,Rel,Init) (5)

[0099] S is a state set, including atomic states and composite states. To express the hierarchical inclusion relationship of the state: (s sp ,s c )∈Child means s c is a composite state s p The direct child state (s p The reachable closure of this relationship forms a state hierarchy tree, with each composite state as a tree node and its substates forming a subnet. is the atomic state subset, and Composite=S\Atomic is the composite state subset.

[0100] T is a set of transitions. Each transition t∈T can connect several states as sources to several states as targets. In order to unify the representation, we define two functions: and The source state set and target state set of the migration are given respectively. Represents the state set that needs to be left after the migration trigger, and the target state set It represents the state set entered after the migration is completed.

[0101] E is a set of events. Assume that events can be triggered or sensed by migrations. Define function F T :T→2 E , which represents the set of events generated when the migration is triggered (generally F T (t) contains at most one event, corresponding to the single event identifier accompanying the transition. Each transition also has a guard condition, Guard(t), which is a logical expression of the current state configuration and the event. If the transition is sensitive to an event, that event appears in the guard condition.

[0102] R is a global set of resource types. Each resource r∈R has a capacity function C(r) (which can be a natural number or infinity to indicate no restrictions). Define Req:T→R×N and Rel:T→R×N to map each migration to its requested and released resources and quantities (which can be viewed as a multiset). When (Req(t)) means that t does not need r; similarly, Rel defines release. is the set of initially active states, which contains the initial state of the top-level network and the initial substates of each concurrent region. For simplicity, we can assume that for each composite state s,Init contains at most one substate of s, which represents the initially active substate when entering s.

[0103] 42) Semantically, a HCSTN configuration is represented by (M, Cnt), where is the set of currently active atomic states (constituting a legal cross-section of each level), and Cnt:R→N gives the currently available quantity of each resource. The initial configuration (M0, Cnt0) satisfies: M0 contains all top-level atomic states in Init (and the initial states of concurrent regions), and Cnt0(r) = C(r) for all r∈R. A migration t is enabled in a configuration (M, Cnt) if and only if:

[0104] a) Status Prerequisites: (Migrate all source states currently active);

[0105] b) Guard condition: Guard(t) is true under the current global state / event (including event satisfaction and other subnet state dependencies).

[0106] c) Resource premise: For all (r,n)∈Req(t), Cnt(r)≥n (the required resources are not less than the required free quantity).

[0107] 43) When transition t fires, the system state changes as follows:

[0108] a) New active state set That is, the atomic state of the source state set is exited and the atomic state of the target state set is entered. It should be noted that if Containing a substate of a composite state means entering the composite state; and vice versa. Therefore, this step requires recursive processing of the hierarchical entry / exit logic, activating its initial substate when entering the composite state, and clearing all its nested active states when exiting.

[0109] b) Resource count update: For each (r, n) ∈ Req(t), update Cnt′(r) = Cnt(r) - n (occupied resources); for each (r, m) ∈ Rel(t), update Cnt′(r) = Cnt′(r) + m (released resources). This assumes that resource release occurs immediately at the end of a transition. If a model state is required to represent "resource holdings," resource release can be deferred until the corresponding release action.

[0110] c) Event generation: After a migration occurs, it is accompanied by an event set F T(t) is placed into a pending event queue for other transitions in the same macrostep to see. The event queue follows broadcast semantics—that is, events from t are visible to all guards in all transitions. At the end of the macrostep, external events are cleared, leaving only the state conditions that may be valid.

[0111] The hierarchical concurrent state transition network (HCSTN) method described in the present invention is suitable for the logical deduction and verification of virtual debugging scenarios in a digital twin environment, and provides a unified formal modeling method for concurrent behaviors and resource competition. Its core includes: realizing hierarchical abstract management of macro processes and micro execution details through composite states and subnet mechanisms; realizing dynamic linkage and synchronous interlocking between concurrent components with the help of global event publishing-response and cross-subnet state dependencies; incorporating shared resources into a unified coordination framework through a global resource token mechanism, so as to intuitively express the occupation and release of resources in state transition rules. This method combines the visualization advantages of finite state machines with concurrent expression capabilities, and has the characteristics of modularity, maintainability, ease of hierarchical verification, and deadlock detection and performance bottleneck analysis based on formal semantics. It can be widely used in digital twin virtual debugging and verification of complex production units or software systems.

[0112] Compared with the existing technology, the present invention has the following advantages: this technical solution explores a hierarchical concurrent state transition network method for digital twin virtual debugging, which can provide guiding suggestions for debugging logic deduction during digital twin virtual debugging. On the one hand, by realizing hierarchical abstraction through composite state and subnet mechanism, the overall process can be visualized at the macro level, while the behavior of each execution unit can be accurately portrayed at the micro level, thereby significantly improving the readability and maintainability of the model; on the other hand, with the help of global event publishing-response and cross-subnet conditional dependencies, dynamic linkage and synchronous interlocking between concurrent components are achieved, avoiding the redundancy and error-proneness of traditional global flag polling; in addition, the global resource token mechanism is introduced to incorporate the allocation and release of shared resources into a unified semantic framework, which can intuitively express resource competition and support deadlock analysis, thereby improving the reliability of virtual debugging. Compared with the traditional method that only relies on state transition diagrams (STDs) or other single formal methods, this method has both intuitiveness and formal verification capabilities, which helps to improve the efficiency and controllability of modeling and verification when dealing with complex concurrent processes. In summary, while maintaining the advantages of visualization, the present invention integrates formal semantics and concurrent control mechanisms, providing a more efficient, reliable and easy-to-maintain modeling and verification method for digital twin virtual debugging. BRIEF DESCRIPTION OF THE DRAWINGS

[0113] Figure 1 Schematic diagram of the layered expansion of the HCSTN model of the present invention;

[0114] Figure 2 Schematic diagram of synchronization events of the dynamic linkage mechanism of the HCSTN model of the present invention;

[0115] Figure 3 Schematic diagram of the global resource coordination mechanism of the HCSTN model of the present invention;

[0116] Figure 4 Schematic diagram of HCSTN of an embodiment of the present invention; DETAILED DESCRIPTION

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

[0118] Example:

[0119] This example focuses on an automated assembly system for electric poles, where the outer sleeve riveting station is responsible for the critical task of precisely positioning and riveting the semi-finished "metal outer sleeve + sleeve" assembly from the previous station. We have constructed a temporal logic (LTL) representation for this station in the automated assembly system. Next, we need to analyze hierarchical subnet modeling, dynamic linkage mechanisms, and global resource coordination mechanisms to construct a hierarchical concurrent state transition network (HCSTN) for this example.

[0120] Figure 4 As shown in the figure, a hierarchical concurrent state migration network method for digital twin virtual debugging is proposed.

[0121] The specific process of hierarchical subnet modeling is as follows:

[0122] 11) Top-level status and subnet division:

[0123] a) Extracting top-level key state nodes: Based on the overall workstation business process, identify the top-level state set (in this example: Idle, Clamping, Pressing, Unclamping, Error), and construct a top-level state transition diagram based on this. This diagram clearly defines the legal transition paths between states and the corresponding trigger conditions. The top-level transition diagram only reflects the macro-process stage and does not include specific execution details, but it does need to note the associated events with the underlying subnets.

[0124] b) Divide the underlying subnets by function or actuator: Divide the action logic corresponding to the system function or physical actuator into several underlying subnets, each of which corresponds to a composite state: Clamping subnet (screw motor extension / position logic), Pressing subnet (TOX riveting cylinder pressing / force value monitoring logic), Unclamping subnet (unclamping and resetting action logic), and Error subnet (fault handling logic). Each composite state is represented as a node in the HCSTN, which contains the detailed state and migration of the subnet.

[0125] c) Clarify the activation / deactivation relationship between the top layer and subnets: In the top layer migration, define when to activate or exit each subnet: When the top layer changes from Idle to Clamping, the Clamping subnet is activated; after the Clamping subnet is completed (broadcast completion event), the top layer is driven from Clamping to Pressing, and then the Pressing subnet is activated; after the Pressing subnet is completed, the top layer is driven from Pressing to Unclamping, and the Unclamping subnet is activated; when any subnet has an abnormality, the top layer enters the Error state and activates the Error subnet; after the Error subnet is completed, the top layer returns to Idle.

[0126] 12) Extracting atomic states and events within the subnet:

[0127] a) Sort out atomic states and initial / end nodes: For each underlying subnet, identify the atomic states that cannot be decomposed any further, and determine the initial state and the reachable end state: Clamping subnet: Idle (standby), Extending (extending), Done (completed in place), Error (fault), initial Idle, end Done or Error; Pressing subnet: Idle, Pressing (pressing down), Done (successfully completed), Error (fault), initial Idle, end Done or Error; Unclamping subnet: Idle, Unclamping (resetting), Done, initial Idle, end Done; Error subnet: FaultLatch (fault latch), AlarmOn (alarm hold), ResetDone (reset completed), initial FaultLatch, end ResetDone.

[0128] b) Extract internal trigger events / signals: For each subnet, list the events or signal types required to trigger migration: sensor feedback, timeout signals, action command signals, reset command signals, etc.; make it clear that these events will serve as migration trigger conditions or migration trigger preconditions in the HCSTN; and broadcast the corresponding events during completed or abnormal migration to notify the top layer or other subnets.

[0129] c) Clearly define the initial and completion flags: For each subnet, define the initial atomic state upon entry; define the completion event / signal to be issued upon completion; define the exception event / signal to be issued in the event of an exception; to ensure that subsequent top-level or parallel subnets can respond.

[0130] 13) Define the state transition structure within the subnet:

[0131] a) Draw a detailed subnet state transition diagram: Based on the extracted atomic states and events, draw a state transition diagram for each subnet: nodes represent atomic states, and edges represent transitions; annotate the transitions: source state → target state, trigger conditions (events, state dependencies, timeouts, etc.), resource request or release annotations, and accompanying event output (broadcast after completion / exception).

[0132] b) For each transition, specify the source and target states, trigger conditions, resource request / release, and event output. For example, for the Clamping subnet, the source and target states are: T1_ScrewExtendCmd: Idle → Extending. The transition trigger condition (Guard) is receiving the extend command and available resources, Req(R). There is no event output, or "ClampingStarted" can be marked as needed. The trigger condition is: T2_ScrewPosSensor: Extending → Done. The transition trigger condition is the in-position sensor trigger, Rel(R), and the output is "ClampDone." The resource request / release is: T3_Timeout: Extending → Error. The transition trigger condition is a timeout signal, Rel(R), and the output is "ClampTimeout." The event output is: T4_Reset: Error / Done → Idle. The transition trigger condition is the reset command, no resource request, and preparation for the next cycle. The remaining subnet transitions are defined similarly.

[0133] 14) Establish linkage between the top layer and subnets:

[0134] a) Mapping completion flags to top-level trigger events: Map the events broadcast during the completion or abnormal migration of each subnet to the trigger preconditions for the top-level migration. For example, the trigger condition for the top-level Clamping→Pressing migration is "receiving the ClampDone event"; the trigger condition for the top-level Error migration is "receiving a fault event from any subnet."

[0135] b) Add a completion event pre-condition to the top-level transition: On the edge of the top-level state transition, mark the trigger pre-condition checkbox.

[0136] Condition: The corresponding subnet must have exited the completed / failed state and broadcast the corresponding event before the top-level migration can be activated.

[0137] c) Add a top-level state dependency to subnet startup migrations: Add a dependency on the top-level state being in place or a top-level event to the migration trigger conditions for the first migration within a subnet (a migration starting from the Idle state) or a key startup migration. For example, add "the top-level state is currently in the Pressing composite state" or "a PressStart event broadcast from the top-level state" to the migration trigger conditions for the Pressing subnet's PressCmd migration. This ensures that subnets are activated only after the top-level state enters the corresponding phase. Uniformly define cross-layer / cross-subnet event identifiers and broadcast them immediately when a subnet migration is triggered. This event can be detected in the same macro step for the migration trigger conditions of the top-level and other subnets, enabling dynamic linkage.

[0138] 15) Integrate to form a complete HCSTN hierarchy:

[0139] a) In the overall HCSTN model, the nodes and edges of the top-level state transition graph are first retained;

[0140] b) Insert each subnet into the corresponding composite state (the composite state contains the complete STD of the corresponding subnet);

[0141] c) Define the entry / exit mechanism of the composite state: upon entry, activate the initial state in the subnet; upon exit, wait for the subnet to enter the end state and emit a completion event;

[0142] d) Establish resource tokens and event broadcast channels between the top layer and the subnet to ensure that the two are executed in coordination and meet resource mutual exclusion requirements.

[0143] Through the above hierarchical subnet modeling process, the organic connection between the top-level state and the bottom-level subnet is completed, and the clear visualization of the macro process flow and the accurate characterization of the micro equipment action are achieved. At the same time, dynamic linkage is established through event broadcasting and triggering preconditions, and a global resource token mechanism is integrated to ensure resource mutual exclusion and concurrent collaboration, ultimately forming a verifiable HCSTN model.

[0144] The specific process of building a dynamic linkage mechanism is as follows:

[0145] 21) Identify concurrent subnets and linkage requirements:

[0146] a) Determine the dynamic linkage subnets: Clamping subnet: responsible for clamping parts in the workstation, including key states such as "Idle", "Clamping", "ClampedDone", "Error", etc.; Pressing subnet: responsible for performing the press riveting operation on the clamped parts, including states such as "Ready / Idle", "Pressing", "PressDone", and "Error".

[0147] b) Clarify the order and mutual exclusion relationship of actions: Order of precedence: Only when the clamping subnet completes "clamping" and enters the ready state can the "start riveting" migration of the rivet subnet be triggered; Mutual exclusion inhibition: During the period when the rivet subnet is in the "riveting" state, the clamping subnet must not perform actions such as "releasing clamping" or re-clamping and remain locked; similarly, after the clamping subnet has just occupied the fixture, the rivet subnet should not be started before the actual clamping is completed.

[0148] c) List the trigger and inhibition conditions: Trigger condition example: The clamping completion migration output event (such as ClampDone) enables the "Start Pressing" migration of the riveting subnet; Inhibition condition example: When the riveting subnet is in the "pressing" state or has obtained the riveting resources, the "Release Clamp" or "Re-clamp" migration of the clamping subnet must be locked until the pressing is completed and the "PressDone" or "PressError" event is broadcast.

[0149] 22) Define the global event publishing-response mechanism:

[0150] a) Specify event outputs for key transitions: Clamping subnet (Clamping): "Clamping completed" transition (Clamping→Done status): output event ClampDone; "Clamping exception" transition (Clamping→Error): output event ClampError; "Release or reset" transition (Error / Done→Idle): output ClampResetDone as needed to prepare for the next round of clamping or other subnet actions. Pressing subnet (Pressing): "Start pressing" transition (Idle / Ready→Pressing): output event PressStart; "Pressing completed" transition (Pressing→Done): output event PressDone; "Pressing exception" transition (Pressing→Error): output event PressError; "Reset" transition (Error / Done→Idle): output PressResetDone to notify the clamping subnet and others to enter the next cycle.

[0151] b) Declare the sensitivity to the event in the target subnet migration trigger condition: Migration trigger condition for the "Start Pressing" migration of the pressing subnet: declare that the event ClampDone (i.e., clamping is completed) must be received and the resource token must be available; Guard condition for the "Release Clamping" or "Next Clamping" migration of the clamping subnet: declare that the event PressDone or PressError must be received and the subnet is not currently in the state of pressing and occupying resources; if an exception is received, the corresponding recovery logic can also be triggered.

[0152] c) Event broadcast sequence: When the "Clamp Completed" transition of the clamping subnet is triggered, the ClampDone event is immediately broadcast. Within the same macrostep, the "Start Pressing" transition of the press-riveting subnet to be evaluated detects this event and performs an availability check (e.g., resource token). When the "Press Completed" transition of the press-riveting subnet is triggered, the PressDone event is broadcast. The "Release Clamp" or "Prepare for Next Clamping" transition of the clamping subnet can be activated based on this event. If an exception occurs, a PressError is broadcast, and the clamping subnet enters the exception handling or retry process.

[0153] 23) Establish cross-subnet conditions / state dependencies:

[0154] a) Reference the clamping subnet status in the preconditions for triggering the migration of the rivet subnet: for example, the migration trigger condition for the "start rivet" migration is: "The clamping subnet is currently in the "clamping completed ready" state and receives the event ClampDone and the global resource token is available;

[0155] b) Reference to the press sub-net state or resource occupancy in the clamp sub-net migration trigger conditions: for example, the migration trigger condition for the "release clamp" migration: the press sub-net is not currently in the "pressing" state and has received the event PressDone or PressError and the resource token has been returned after the press is completed or an exception;

[0156] c) Enabling condition examples: "the press sub-net'start pressing' migration is triggered only if the clamp sub-net has completed clamping, received the event ClampDone, and the global resource token is available"; "the clamp sub-net'release clamp' or 'next round of clamping' migration is triggered only if the press sub-net has completed pressing or exception handling, received the event PressDone / PressError, and the resource token has been returned".

[0157] 24) Configure resource mutual exclusion or complementary positions:

[0158] a) Create a global resource token: create a global resource token for the "clamping / pressing shared station or fixture resource" at model initialization, for both parties to request occupancy before the key migration trigger and release after completion.

[0159] b) Declare token request and release on the relevant migration:

[0160] Clamp sub-net: "clamp start" migration (Idle→Clamping) requests 1 resource token; at this time, the resource is occupied, preventing the press sub-net from occupying at the same time; "clamp completion migration" (Clamping→Done) or "clamp exception" migration (Clamping→Error) releases the token; outputs the event ClampDone or ClampError; "release clamp / reset" migration (Done / Error→Idle) usually does not request resources, only after receiving the press completion event;

[0161] Press sub-net: "start pressing" migration (Idle→Pressing) requests 1 resource token; needs to be triggered after receiving the event ClampDone and the token is available; "press completion" migration (Pressing→Done) or "press exception" migration (Pressing→Error) releases the token; outputs the event PressDone or PressError; "reset" migration (Done / Error→Idle) usually does not request resources, only after the corresponding event to enter the standby state (Idle).

[0162] c) Mutual exclusion and suppression are achieved through occupation / release: When the clamping subnet first occupies the resource token and enters clamping, the "start clamping" of the rivet-pressing subnet is suppressed due to the unavailable token. When clamping is completed or an exception occurs, the token is released and ClampDone or ClampError is broadcast. The rivet-pressing subnet occupies resources to start clamping when the event is received and the token is available. While clamping is in progress, the "release clamp" or "re-clamp" migration of the clamping subnet is suppressed. When clamping is completed, the token is released and the event is broadcast. After receiving the event, the clamping subnet occupies resources to execute release or the next round of clamping. If two subnet key migrations meet the triggering conditions at the same macro step and both request tokens, the preset conflict resolution strategy (such as first-come, first-served or priority) determines which one occupies first, and the other waits.

[0163] Through the above four steps, we have achieved a systematic description of the triggering and inhibition relationship between concurrent subnets, established a global event publishing-response and cross-subnet state dependency mechanism, and ensured the interlocking and atomic execution of each subnet's actions through mutually exclusive resource locations and synchronous migration groups.

[0164] The specific process of building a global resource coordination mechanism is as follows:

[0165] 31) Identify shared resources and mutual exclusion requirements:

[0166] a) Determine shared resources: In this embodiment, "riveting execution resources" are used to represent the mutually exclusive devices / channels required for the TOX cylinder's pressing action or the lead screw motor's extending action;

[0167] b) Clarify mutual exclusion requirements: The key migration for performing press riveting in the TOX cylinder subnet (Pressing subnet) and the key migration for performing extension / clamping in the lead screw motor subnet (Clamping subnet) must both exclusively occupy this resource. Both cannot occupy it at the same time to prevent mechanical interference or simulation misalignment. In addition, this resource must also be released during the exception handling process to avoid deadlock.

[0168] 32) Define the repository and token initialization:

[0169] a) Create a global place Place (e.g., P_res_ClampPress) for the “clamping execution resource” in the HCSTN model;

[0170] b) Based on the available capacity of the resource, a token is placed in the place, indicating that the resource is initially free and available for occupation;

[0171] 33) Migrate request and release mapping extension:

[0172] a) Add resource requests and releases to the migration definitions for each subnet:

[0173] Screw motor subnet (Clamping subnet): "Clamping start" transition (such as T1_ClampCmd, Idle→Clamping) adds a request set Req(T1) containing one "Riveting execution resource" token; "Clamping completion" transition (such as T2_ClampPosSensor, Clamping→Done) or "timeout failure" transition (T3_ClampTimeout, Clamping→Error) adds a release set Rel(T2, T3) at the end of execution to return one token and output the event ClampDone or ClampTimeout respectively;

[0174] TOX cylinder subnet (Pressing subnet): The "start pressing" transition (such as P1_PressCmd, Idle→Pressing) adds a request set Req(P1) containing a "pressing execution resource" token; the "pressing completion" transition (such as P2_ForceOK, Pressing→Done) or the "pressing exception" transition (such as P3_ForceNotOK, Pressing→Error) adds a release set Rel(P2, P3) to return a token and output the event PressDone or PressError respectively;

[0175] b) Incorporate both resource availability and status / event conditions into the migration trigger conditions to achieve static linkage. For example, the migration trigger condition for the TOX cylinder's "Start Riveting" migration is "receiving the clamping subnet completion event (ClampDone) and the global 'Riveting Execution Resource' token is available." The migration trigger condition for the lead screw motor's "Extend Start" migration is "receiving the top-level Enter Clamping phase event and the global 'Riveting Execution Resource' token is available." By including the availability of resource tokens as one of the prerequisites for migration trigger conditions, static constraints on resource competition are implemented.

[0176] 34) Resource enablement determination and conflict resolution:

[0177] a) Enablement check: When determining whether a transition t can be triggered, you must also check:

[0178] i) Status / event triggering conditions are met;

[0179] ii) For each resource r declared in Req(t), the current number of globally available tokens Cnt(r) ≥ the number of requests;

[0180] Only when both conditions are met, migration t is marked as resource-enabled.

[0181] b) Conflict detection: If multiple migrations satisfy the state / event condition at the same time, but the sum of their requests for the same resource exceeds the available token (in this case, if more than one migration requests the "clamping execution resource" at the same time), a resource conflict occurs;

[0182] c) Conflict resolution strategy: According to the preset priority or nondeterministic strategy, one of the migrations is selected to occupy the token for execution, and the other migrations are suppressed and re-evaluated in the next macro-step. For example, if the start-up migrations of the lead screw motor subnetwork and the TOX cylinder subnetwork both satisfy the state condition and request the resource at the same macro-step, one of them is selected for execution according to the order or priority, and the other is suppressed.

[0183] 35) Migration execution and token synchronization update:

[0184] a) Token deduction at the start of migration: When a resource enables migration t is triggered, the corresponding token is deducted from the global resource pool Cnt according to Req(t), indicating that the resource is occupied;

[0185] b) Token return at the completion of migration or entering an abnormal branch: When the release operation specified in Rel(t) occurs, the token is returned to the global library, restoring the availability of the resource;

[0186] c) Trigger a new round of judgment after release: After the resource token is returned, the suppressed migration due to resource shortage may be awakened, and the availability is re-evaluated in the same macro-step or the next macro-step;

[0187] d) Exception handling to ensure token release: If a fault occurs in the TOX cylinder or lead screw motor subnetwork during operation, the token still occupied by the fault subnetwork should be uniformly released in the entry migration of the fault subnetwork to prevent deadlock.

[0188] The above five steps collectively define the global resource library, migration and resource mapping extension, enablement judgment and conflict handling, as well as token occupation and release during migration execution, thereby realizing unified coordination and mutual exclusion access to shared resources in the HCSTN model.

[0189] 41) HCSTN formal parameter instance of the riveting machine work station:

[0190] In order to facilitate verification, the HCSTN model of the "outer sleeve riveting work station" in this embodiment can be defined in the following nine-tuple formalization:

[0191] H = (S, T, E, R, F S , F T , Req, Rel, Init) (6)

[0192] State set S: contains top-level states and atomic states and composite states of two-layer subnetworks (Clamping, Pressing):

[0193]

[0194] Migration set T: take key migrations,

[0195] T={tC_start,tC_done,tC_err,tP_start,tP_done,tP_err}, (8)

[0196] Event set E:

[0197] E={ClampDone,ClampError,PressStart,PressDone,PressError} (9)

[0198] Source / Destination Mapping F S ,F T :

[0199]

[0200] Global resource type set R:

[0201] R = {Res}, and Cnt(Res) = 1, (11)

[0202] Request / release mapping Req,Rel:

[0203]

[0204] Initial configuration Init=(M0,Cnt0):

[0205] M0={Idle,Idle C ,Idle P}, Cnt0(Res)=1. (13)

[0206] The above nine-tuple strictly describes the state, migration, event and resource model of the "outer sleeve riveting station" HCSTN.

[0207] In summary, the HCSTN model comprehensively describes the dynamic behavior of the outer sleeve riveting machine, and realizes efficient modeling of the riveting station control process through a hierarchical abstraction mechanism, dynamic linkage, and a global resource coordination mechanism. In this embodiment, the actions involved in the riveting station, such as cylinder extension and contraction, positioning detection, and gripper control, are effectively divided into multiple subnets, and dynamic activation and linkage are achieved through top-level scheduling. The resource mutual exclusion relationship is coordinated through a global resource token mechanism to ensure the logical consistency and execution security during the virtual debugging process. This method not only improves the visualization and maintainability of complex processes, but also fully demonstrates the modeling advantages of the method of the present invention in scenarios of multi-device collaboration and key resource competition, providing theoretical support and practical reference for virtual debugging and digital twin modeling of similar equipment.

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

Claims

1. A hierarchical concurrent state migration network method for digital twin virtual debugging, characterized by: The method comprises the following steps, Step 1: Hierarchical subnet modeling, Step 2: Build a dynamic linkage mechanism. Step 3: Build a global resource coordination mechanism.

2. A hierarchical concurrent state migration network method for digital twin virtual debugging according to claim 1, characterized in that: Step 1: The specific process of hierarchical subnet modeling is as follows: 11) Top-level status and subnet division: a) Starting from the overall business process, extract the top-level key state nodes and construct the top-level state transition diagram; b) Divide the system into several underlying subnets according to functions or actuators, each subnet corresponding to a physical sub-process or device action; c) Clarify the activation / deactivation relationship between the top layer and each subnet: the top layer state transition determines when to activate which subnet, and the subnet completion status in turn drives the next step of the top layer; 12) Extracting atomic states and events within the subnet: a) For each underlying subnet, sort out the atomic states involved in the subnet and the corresponding state transition conditions; b) Extract the events or signals required to trigger migration within the subnet, preparing for the subsequent definition of migration trigger conditions and resource requests within the subnet; c) Define the initial and final nodes for each subnet: that is, which atomic state to start from when entering the subnet, and what completion flag to return to or issue after execution; 13) Define the state transition structure within the subnet: a) Based on the extracted atomic states and events, a detailed state transition diagram is drawn for each subnet, including: state nodes (atomic states) and their behavioral semantics, transition edges and their departure conditions, and resource request or release annotations; b) For each transition, specify the source and target states, trigger conditions (events, state dependencies, timeouts), and accompanying event outputs (events to notify the top level or other subnets after the subnet completes); 14) Establish linkage between the top layer and subnets: a) Map the "completion flag" of each subnet to the trigger event of the top-level migration; b) Add a trigger precondition to the top-level migration, requiring the corresponding subnet's completion event to exist (or the subnet to have exited to the specified state); c) In the subnet startup migration, add "top-level status is in place" or "top-level event received" as a trigger precondition to ensure that the subnet is activated only when the top-level state enters the corresponding stage; 15) Integrate to form a complete HCSTN hierarchy: a) In the overall HCSTN model, the nodes and edges of the top-level state transition graph are first retained; b) Insert each subnet into the corresponding composite state (the composite state contains the complete STD of the corresponding subnet); c) Define the entry / exit mechanism of the composite state: upon entry, activate the initial state in the subnet; upon exit, wait for the subnet to enter the end state and emit a completion event; d) Establish resource tokens and event broadcast channels between the top layer and the subnet to ensure that the two are executed in coordination and meet resource mutual exclusion requirements.

3. A hierarchical concurrent state migration network method for digital twin virtual debugging according to claim 1, characterized in that: Step 2: Build a dynamic linkage mechanism, as follows: 21) Identify concurrent subnets and linkage requirements: a) Identify the concurrent subnetworks in the model that need to collaborate or interlock with each other, and clarify the order or mutual exclusion relationship between their actions; b) For each pair of subnets that need to be linked, list the trigger conditions (when one subnet is completed, the other subnet needs to be notified) and the corresponding suppression conditions (when one subnet is in progress, the other subnet needs to be locked). 22) Define the global event publishing-response mechanism, a) Specify event output for key migration in HCSTN to notify other subnets; b) Declare sensitivity to this event in the migration trigger condition of the target subnet to ensure synchronous activation within the same macro step; c) When a migration condition is triggered, the corresponding event is immediately broadcast globally, and all migrations waiting for the event in the triggering process will be checked for availability in parallel. 23) Establish cross-subnet conditions / state dependencies: a) Reference the active status of subnet B in the migration trigger preconditions of subnet A, and vice versa, to form a clear cross-subnet dependency; b) Include "Subnet B is in state s" and "Event E received" as trigger conditions for a migration in Subnet A, implementing a static linkage mechanism where the migration is triggered only when other subnets meet specific states and events. 24) Configure resources to mutually exclusive or complementary positions: a) If two or more subnets need to mutually exclusive occupy the same resource during an action, a global mutually exclusive shared resource (Place) is created for the resource in the HCSTN, which contains the corresponding mutually exclusive token (Token); b) Declare a request (Req) for the exclusive position token on the key migration of the relevant subnet, automatically blocking similar migrations of other subnets after taking it; return the token by releasing (Rel) when the action is completed; c) Through the occupation / release of resource tokens, mutual exclusion and linkage suppression during the action period are achieved. 25) Define the synchronous migration group: a) For multiple transitions that need to be triggered strictly synchronously (multiple transitions fire together), mark them as the same synchronization group; b) Alternatively, combine these migrations into a composite migration, set unified multi-source and multi-target states, and ensure that either they are triggered simultaneously or not at all; c) Bind the same synchronization event or cross-subnet state prerequisite to the triggering preconditions of all synchronous migrations to maintain the atomicity of the actions.

4. A hierarchical concurrent state migration network method for digital twin virtual debugging according to claim 1, characterized in that: Step 3: Build a global resource coordination mechanism, as follows: 31) Identify shared resources and mutual exclusion requirements, a) Identify the global resources that all concurrent subnets in the system need to contend for, and identify which subnets should maintain mutually exclusive access to the same resource, 32) Define the resource repository and token initialization, a) For each shared resource r (r∈R), a corresponding shared resource place is created in the HCSTN model, and a corresponding number of tokens are placed in the place according to the capacity of the resource. 33) Migrate request and release mapping extension, a) In the definition of each migration t, add Request set Req(t): indicates the resources and token count required before triggering; Release set Rel(t): indicates the resources and token number that need to be returned after triggering. b) Include "Subnet B is in state s" and "Event E received" as trigger conditions for a migration in Subnet A, implementing a static linkage mechanism where the migration is triggered only when other subnets meet specific states and events. 34) Resource enablement determination and conflict resolution, a) When determining whether a migration t can be triggered, simultaneously check that its state / event conditions and all (r,n)∈Req(t) satisfy Cnt(r)≥n. If multiple migrations compete for the same resource and there are insufficient tokens available, one of the migrations is selected to occupy the token according to the preset priority or non-deterministic strategy, and the others are re-determined in the next macro step. 35) Migration execution and token synchronization update, a) When the migration starts executing, the corresponding token is deducted from the global resource map Cnt according to Req(t).

5. A hierarchical concurrent state migration network method for digital twin virtual debugging according to claim 1, characterized in that: The method also The following steps are included: Step 4: Construct a formal model of HCSTN. 41) A HCSTN model is defined as a nine-tuple: H=(S,T,E,R,F S ,F T ,Req,Rel,Init) (1) S is a state set, including atomic states and composite states, using a relationship To express the hierarchical inclusion relationship of the state: (s sp ,s c )∈Child means s c is a composite state s p The direct child state of s p It must be a composite state. Each composite state is a tree node, and its sub-state set forms a subnet. is the atomic state subset, Composite=S\Atomic is the composite state subset, T is a set of transitions. Each transition t∈T connects several states as sources to several states as targets. In order to unify the representation, two functions are defined: and The source state set and target state set of the migration are given respectively, where the source state set Represents the state set that needs to be left after the migration trigger, and the target state set It represents the state set entered after the migration is completed. E is a set of events. Assuming that the events are triggered or sensed by migration, define the function F T :T→2 E , which represents the set of events generated when the migration is triggered (F T (t) contains at most one event, corresponding to the single event identifier accompanying the transition). At the same time, each transition has a guard condition Guard(t), which is a logical expression about the current state configuration and events. If the transition is sensitive to an event, the event appears in the guard condition. R is a set of global resource types. Each resource r∈R has a capacity function C(r). Define Req:T→R×N and Rel:T→R×N to map each migration to its requested and released resources and quantities. When t does not need r; Rel defines release, is the set of initially active states, which contains the initial state of the top-level network and the initial substate of each concurrent region. Assume that for each composite state s, Init contains at most one substate of s, which represents the initial active substate when entering s. 42) Semantically, a HCSTN configuration is represented by (M, Cnt), where is the set of currently active atomic states (constituting a legal cross-section of each level), Cnt:R→N gives the currently available quantity of each resource, and the initial configuration (M0, Cnt0) satisfies: M0 contains all top-level atomic states in Init, and Cnt0(r) = C(r). For all r∈R, a migration t is enabled in the configuration (M, Cnt) if and only if: a) Status Prerequisites: (Migrate all source states currently active); b) Guard condition: Guard(t) is true under the current global state / event (including event satisfaction and other subnet state dependencies). c) Resource premise: for all (r,n)∈Req(t), Cnt(r)≥n (the required resources are not less than the required free quantity); 43) When transition t fires, the system state changes as follows: a) New active state set That is, the atomic state of the source state set is exited and the atomic state of the target state set is entered. If Containing a substate of a composite state means entering the composite state; vice versa. This step requires recursive processing of the hierarchical entry / exit logic. When entering a composite state, its initial substate is activated, and when exiting, all nested active states are cleared. b) Resource count update: For each (r, n) ∈ Req(t), update Cnt′(r) = Cnt(r) - n (occupied resources); for each (r, m) ∈ Rel(t), update Cnt′(r) = Cnt′(r) + m (released resources). If the model state needs to indicate "resource holding", the resource release can be delayed until the migration of the corresponding release action. c) Event generation: After a migration occurs, it is accompanied by an event set F T (t) is put into a pending event queue for other transitions in the same macrostep to perceive. The processing of the event queue follows the broadcast semantics - that is, the event of t is visible to the guards of all transitions. When the macrostep ends, the external events are cleared and only the state conditions that may continue to be valid are retained.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, it implements a hierarchical concurrent state migration network method for digital twin virtual debugging as described in any one of claims 1 to 5 above.

7. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the computer instruction is executed by the processor, a hierarchical concurrent state migration network method for digital twin virtual debugging according to any one of claims 1 to 5 is implemented.

Images