A hierarchical concurrent state migration network method for digital twin virtual commissioning

Abstract

The present application relates to a kind of hierarchical concurrent state migration net methods for digital twin virtual debugging, the main principle and structure of mechanism that the method has and main construction process are listed;The method is realized by composite state and subnet mechanism hierarchical abstract management of macroscopic process and microscopic execution details, utilizes global event publishing-response and cross-subnet state dependence mechanism to realize the dynamic linkage and synchronous interlocking between concurrent components, and the mutual exclusion access and release of shared resources are completed in combination with global resource token mechanism.Based on this, visual and verifiable concurrent process model can be generated in virtual debugging environment, and deadlock detection and resource bottleneck analysis are supported, thereby significantly improving the accuracy, reliability and maintainability of complex production unit or software system digital twin virtual debugging.

Description

Technical Field

[0001] This invention specifically relates to a logic deduction method in a virtual debugging process, and more specifically to a Hierarchical Concurrent State TransitionNet (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 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 and verification platform for the commissioning process by accurately replicating the structure, behavior, and interactions of physical equipment in virtual space. However, with the surge in the number of production unit devices, the increase in process coupling, and the enhancement of concurrent collaboration, traditional virtual commissioning methods struggle to meet the following requirements:

[0003] (1) Complexity and Concurrency of Debugging Logic: In actual production processes, there are strict timing requirements among various devices, including startup sequence, synchronization constraints, resource contention and mutual exclusion, and timeout response. Traditional methods based on manual experience or simplified finite state machines (FSMs) are difficult to formally and comprehensively describe and verify these complex constraints. If any step in the process has a flaw in its timing logic or resource allocation logic, it may lead to distortion of simulation results, resulting in safety hazards or performance bottlenecks during the physical debugging phase.

[0004] (2) Insufficient formal verification capability: 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 subprocesses are difficult to express intuitively, and resource occupation and release are not included in the formal model, making it difficult to detect and locate risks such as deadlock, competition and starvation in a timely manner, resulting in low simulation verification efficiency and limited coverage.

[0005] (3) Resource competition and deadlock risk: In modern production units, various 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, the occupation and release of shared resources by each submodule can only be hard-coded in the form of "variable flags" or "extra branches," which is neither intuitive nor convenient for formal analysis, and makes it difficult to detect possible deadlocks and performance bottlenecks in advance.

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

[0007] To address the shortcomings in modeling concurrent behavior and resource contention during virtual debugging in existing technologies, this invention proposes a hierarchical concurrent state transition network (HRNN) method for digital twin virtual debugging. This method formally describes the concurrency and resource constraints of each subprocess, employs hierarchical abstraction for multi-level management of system states, and achieves dynamic linkage between subnets through event broadcasting and conditional dependencies. Simultaneously, a global resource token mechanism is used to ensure mutual exclusion access and release of shared resources. Utilizing the HSTN model, a visual and verifiable virtual debugging process can be generated, supporting deadlock detection and resource bottleneck analysis. The specific technical solution of this invention is as follows:

[0008] (1) Hierarchical abstraction mechanism;

[0009] (2) Dynamic linkage mechanism;

[0010] (3) Global resource coordination mechanism;

[0011] (4) HCSTN formal model.

[0012] HCSTN's hierarchical abstraction mechanism aims to organize states or subnets hierarchically, expanding from the top to the bottom layer, decomposing complex systems into sub-models of different granularities. Each layer focuses on a specific function; higher layers are responsible for scheduling, while lower layers provide execution details, maintaining clear boundaries and interfaces between layers. This structure ensures semantic consistency and improves the readability and maintainability of the model.

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

[0014] HCSTN employs a combination of composite states and subnets to achieve hierarchical abstraction. The model includes both indivisible atomic states and composite states with nested subnets. The latter are represented externally as single high-level nodes, while internally, subnets characterize more fine-grained dynamic behavior. When the system enters a composite state, its corresponding subnet is activated; when the system leaves, the subnet ceases operation. 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 low-level execution details can be achieved while maintaining semantic consistency of the model.

[0015] For example, appendix Figure 1 A two-layer HCSTN network is shown. The top-level state container network contains one atomic state C and two composite states A and B. The structure of composite state B (composed of substates S1, S2, S3, S4, S5 and their transitions) is shown on its right side. 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] To ensure the mutual exclusion and completeness of the composite state with other global state sets, we further introduce the following formula:

[0017] Formula (1) Hierarchical abstraction of independence constraints:

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

[0019]

[0020] The first equation guarantees that the subnet state belongs to the global state set, and the second equation guarantees that the internal state and the external state of the subnet are mutually exclusive.

[0021] Before hierarchical subnet modeling, the system has formalized the key temporal constraints based on Linear Temporal Logic (LTL) and mapped these constraints to executable node and edge conditions using a traditional State Transition Graph (STD). Since this invention focuses on extending the existing STD model into a hierarchical and concurrent HCSTN, the details of LTL and STD construction are omitted below. The explanation will directly focus on the generation and organization process of the hierarchical state transition graph. The specific process of hierarchical subnet modeling is as follows:

[0022] 11) Top-level state and subnetting:

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

[0024] b) Divide the system into several underlying subnets according to function or actuator, with each subnet corresponding to a physical subprocess 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 completion status of the subnet, in turn, drives the next step of the top layer.

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

[0027] a) For each bottom-level subnet, identify the atomic states involved in that subnet and their corresponding state transition conditions;

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

[0029] c) Define the initial / end node for each subnet: that is, from which atomic state to start when entering the subnet, and what kind of 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, draw a detailed state transition diagram for each subnet, including: state nodes (atomic states) and their behavioral semantics, transition edges and their starting conditions, and resource request or release annotations;

[0032] b) Specify the source and target states, triggering conditions (events, state dependencies, timeouts, etc.) and accompanying event outputs for each migration (events to notify the top layer or other subnets after the subnet is completed).

[0033] 14) Establish the linkage between the top-level network and subnets:

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

[0035] b) Add a triggering precondition to the top-level migration, requiring the existence of the completion event of the corresponding subnet (or the subnet has exited to the specified state);

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

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

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

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

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

[0041] d) Establish a resource token and event broadcast channel between the top layer and the subnet to ensure that the two work together and meet the resource mutual exclusion requirements.

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

[0043] HCSTN's dynamic linkage mechanism introduces event broadcasting, condition monitoring, and synchronization constraints into the model, enabling different sub-models to link together based on their current state during runtime by combining or sharing events. Whether it is unidirectional triggering or 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 as follows:

[0045] The dynamic linkage mechanism in HCSTN comprises two parts: First, a global event publishing-response system is introduced: when a migration occurs, an event identifier is issued, and other migrations declare their sensitivity to this event in their trigger conditions. When the migration generates an event, it is immediately broadcast globally to HCSTN, and all migrations waiting for the event are simultaneously activated and undergo condition checks. Second, regarding 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 trigger prerequisite, thus explicitly specifying in the model which state combinations should trigger a linked transition. Combined with the event mechanism, various complex concurrent interaction patterns can be expressed.

[0046] When inter-subnet linkage requires both "cross-subnet events" and "local conditions" to be met, 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 it must meet its local condition C A Then its migration trigger condition is Guard(t) A ) is defined as:

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

[0050] In addition, HSTN provides the concept of synchronous migrations: when multiple migrations need to be executed in strict synchronization, they can be marked as the same synchronization group or a common synchronization event can be set to ensure that these migrations either trigger at the same time or none of them trigger.

[0051] For example, appendix Figure 2 As shown, there are two parallel lines, each with a transition T1 and T2. We want them to occur simultaneously (either both occur or neither occurs). In HSTN, we can merge T1 and T2 into a complex transition with two source states and two target states, or we can set a common synchronization event for them so that they are triggered at the same logical moment.

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

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

[0054] a) Identify the concurrent subnets in the model that need to cooperate or interlock with each other, and clarify the order of actions or mutual exclusion relationships between them;

[0055] b) For each pair of subnets that need to be linked, list the triggering conditions (when one subnet completes, it needs to notify the other subnet) and the corresponding suppression conditions (when one subnet is in progress, it needs to lock the other subnet).

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

[0057] a) Specify event outputs (such as completion flags, exception flags, etc.) for critical migrations in HSTN to notify other subnets;

[0058] b) Declare sensitivity to the event (“Event E received”) in the migration trigger condition of the target subnet to ensure synchronous activation within the same macrostep;

[0059] c) When a migration condition is triggered, the corresponding event is immediately broadcast globally, and all migrations waiting for the event will undergo availability checks in parallel.

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

[0061] a) Reference the activity state of subnet B in the migration triggering preconditions of subnet A, and vice versa, to form an explicit cross-subnet dependency;

[0062] b) Incorporate both "subnet B is in state s" and "event E is received" into the triggering conditions for a migration in subnet A, thereby achieving a static linkage that "only triggers when other subnets meet specific states and events";

[0063] 24) Configure mutually exclusive or complementary resource locations:

[0064] a) If two or more subnets need to mutually exclude the same resource during an action, a global mutually exclusive shared resource (Place) is created for that resource in HSTN, which contains the corresponding mutual exclusion token.

[0065] b) Declare a request (Req) for the exclusive location token on a critical migration in the relevant subnet, automatically preventing similar migrations in other subnets after the token is claimed; return the token by releasing (Rel) when the action is complete;

[0066] c) Mutual exclusion and linkage inhibition during the action are achieved by occupying / releasing resource tokens.

[0067] 25) Define the synchronization migration group:

[0068] a) For multiple transitions that require strict synchronous triggering, mark them as the same synchronization group;

[0069] b) Alternatively, these migrations can be merged into a single composite migration, with a unified multi-source state and multi-target state, ensuring that either all migrations are triggered simultaneously or none are triggered at all.

[0070] 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 action;

[0071] Through the above five steps, a systematic description of the triggering and suppression relationship between concurrent subnets is realized, a global event publishing-response and cross-subnet state dependency mechanism is established, and the interlocking and atomic execution of actions in each subnet are ensured 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 repository is created for each type of shared resource in the model, and available capacity is represented by tokens; each transition specifies the number of resources it needs to acquire before triggering, and returns the corresponding tokens upon completion or anomaly; when determining transition triggers, the availability of global tokens is checked first, deducted after use, and returned upon completion or anomaly; when multiple transitions compete for the same resource and there are insufficient tokens, mutual exclusion scheduling is performed according to a preset strategy. This mechanism is compatible with the hierarchical structure and event-driven characteristics of HCSTN, and supports deadlock and resource conflict detection based on formal analysis, thus intuitively and reliably characterizing concurrent resource contention scenarios and 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, shared resources are incorporated into a globally visible resource set R, and their available capacity is represented by tokens, enabling unified management of resource allocation and state transitions. Each transition declares the number of tokens it needs to acquire and release during definition. During execution, the system first checks the global available token quantity for the corresponding resource; if sufficient, tokens are deducted and the transition is allowed; otherwise, it is blocked. Tokens are returned upon transition completion or when entering an abnormal branch, ensuring mutual exclusion between concurrent subnets. When multiple transitions compete for the same resource and there are insufficient available tokens, a preset conflict resolution strategy is used to select the transition to execute, while the remaining transitions enter a waiting state. Resource occupancy status is considered part of the system configuration. Based on this mechanism, formal analysis can be used to detect potential deadlocks and resource contention, thereby ensuring the correctness and safety of resource scheduling under dynamic operation.

[0075] For example, appendix Figure 3 As shown, there is a global resource R (initially 1 unit). Subtask 1 transitions from state X to state Y via transition T1, and T1 needs to acquire resource R during execution. Subtask 2 transitions from state U to state V via transition T2, and T2 also needs to acquire R. Solid arrows represent state transitions, and dashed arrows represent resource acquisition and release relationships. Before triggering, both transitions T1 and T2 check if resource R is available. If it is available, they acquire it (reducing the available amount of R to 0). Since R has only 1 unit, T1 and T2 cannot be granted permission simultaneously: if one executes first and acquires R, the other must wait until the resource is released. Subsequently, when T1 or T2 completes execution, it releases R (restoring the available amount of R to 1), thus waking up the other waiting transition. In this way, the HSTN model ensures mutual exclusion access to shared resources by concurrent tasks, 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) Identify the global resources that all concurrent subnets in the system need to contend for, and determine which subnets should maintain mutual exclusion for access to the same resource.

[0079] 32) Define the initialization of the resource repository and tokens:

[0080] a) Create a corresponding shared resource place in the HCSTN model for each shared resource r (r∈R), and place the corresponding number of tokens in the place according to the capacity of the resource.

[0081] 33) Migration requests and release mapping extensions:

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

[0083] Request set Req(t): Indicates the resources and tokens required before triggering;

[0084] Release set Rel(t): Indicates the resources and their token count that need to be returned after the release is triggered.

[0085] b) Incorporate both "subnet B is in state s" and "event E is received" into the triggering conditions for a migration in subnet A, thereby achieving a static linkage that "only triggers when other subnets meet specific states and events";

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

[0087] a) When determining whether migration t can be triggered, simultaneously check that its state / event conditions satisfy Cnt(r)≥n for all (r,n)∈Req(t). If multiple migrations compete for the same resource and there are insufficient available tokens, select one migration to occupy the token according to a preset priority or a non-deterministic strategy, and re-determine the others in the next macrostep.

[0088] b) To rigorously characterize resource requests and enable decisions, a further formula is introduced:

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

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

[0091] Migration t is enabled under configuration (M, cnt) if and only if:

[0092]

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

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

[0095] a) When the migration begins, the corresponding token is deducted from the global resource map Cnt based on Req(t).

[0096] The above five steps together complete the definition, migration and resource mapping extension of the global resource repository, enable determination and conflict handling, as well as the token holding and release during the migration execution process, thereby realizing unified coordination and mutual exclusion access to shared resources in the HSTN model.

[0097] 41) 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 set of states, containing atomic states and composite states. This can be represented by a relation. To represent the hierarchical containment relationship of states: (s sp ,s c )∈Child means s c It is a composite state s p direct substates (s) p (Must be a composite state). The reachability closure of this relationship forms a state hierarchy tree, with each composite state as a tree node, and its child states forming a subnet. Let... S is a subset of atomic states, and Composite = S\Atomic is a subset of composite states.

[0100] T is the set of transitions. Each transition t∈T can connect several states as sources to several states as destinations. For a unified representation, two functions are defined. and The source state set and the target state set for the transition are given respectively. The source state set... This represents the set of states that need to be left to trigger the migration, and the target state set. This represents the set of states entered after the migration is complete.

[0101] E is a set of events. It is assumed that events can be triggered or perceived through migration. Define a function F. T :T→2 E , represents the set of events generated when a migration is triggered (generally F) T (t) contains at most one event, corresponding to a single event identifier accompanying the migration. Additionally, each migration has a guard condition, Guard(t), which is a logical expression regarding the current state configuration and events. If a migration is sensitive to a certain 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, without restriction). Define Req:T→R×N, Rel:T→R×N to map each resource requested and released and its quantity (which can be viewed as a multiset). (Req(t)) indicates that t does not need r; similarly, Rel defines release. It is the initial set of active states, which includes the initial state of the top-level network and the initial sub-states of each concurrent region. For simplicity, it can be assumed that for each composite state s, Init contains at most one sub-state of s, representing the initial active sub-state when entering s.

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

[0104] a) State premise: (All source states for migration are currently active);

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

[0106] c) Resource prerequisite: For all (r,n)∈Req(t), Cnt(r)≥n (the required resources are not less than the required number of available resources).

[0107] 43) When migration t occurs (fire), the system state will change as follows:

[0108] a) New set of active states That is, atomic states of the source state set are exited, and atomic states of the target state set are entered. It is important to note that if... A substate containing a composite state indicates entry into that composite state; conversely, exiting it indicates exiting. Therefore, this step requires recursively handling the logic of hierarchical entry / exit: activating the initial substate when entering a composite state, and clearing all nested active states when exiting.

[0109] b) Resource count update: For each (r,n)∈Req(t), update Cnt′(r) = Cnt(r) - n (resource held); for each (r,m)∈Rel(t), update Cnt′(r) = Cnt′(r) + m (relevant resource released). It is assumed that resource release occurs immediately at the end of the transition. If the model state needs to represent "resource holding," resource release can be deferred to the transition corresponding to the release action.

[0110] c) Event Generation: After the migration occurs, its accompanying event set F T`t` is added to a queue of events to be processed, making it visible to other transitions within the same macrostep. The processing of the event queue follows broadcast semantics—that is, events of `t` are visible to the guards of all transitions. At the end of the macrostep, external events are cleared, retaining only state conditions that may remain valid.

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

[0112] Compared to existing technologies, this invention offers the following advantages: It explores a hierarchical concurrent state transition network method for digital twin virtual debugging, providing guidance for the deduction of debugging logic during the digital twin virtual debugging process. Firstly, by implementing hierarchical abstraction through composite states and subnet mechanisms, the overall process can be visualized at the macro level while accurately depicting the behavior of each execution unit at the micro level, significantly improving the model's readability and maintainability. Secondly, by leveraging 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. Furthermore, the introduction of a global resource token mechanism incorporates shared resource allocation and release into a unified semantic framework, intuitively expressing resource contention and supporting deadlock analysis, thus improving the reliability of virtual debugging. Compared to traditional methods that rely solely on state transition diagrams (STDs) or other single formal methods, this method combines intuitiveness with formal verification capabilities, helping to improve the efficiency and controllability of modeling and verification when handling complex concurrent processes. In summary, this invention, while maintaining the advantages of visualization, integrates formal semantics and concurrency control mechanisms, providing a more efficient, reliable, and easy-to-maintain modeling and verification method for digital twin virtual debugging. Attached Figure Description

[0113] Figure 1 This is a schematic diagram of the hierarchical expansion of the HCSTN model of the present invention;

[0114] Figure 2 This is a schematic diagram of the dynamic linkage mechanism synchronization event of the HSTN model of the present invention;

[0115] Figure 3 This is a schematic diagram of the global resource coordination mechanism of the HSTN model of the present invention;

[0116] Figure 4 This is a schematic diagram of an embodiment of the present invention, HCSTN; Detailed Implementation

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

[0118] Example:

[0119] This embodiment focuses on an automated assembly system for an electric strut. The outer sleeve riveting station is crucial for accurately positioning and riveting the semi-finished assembly from the previous station, the "metal outer sleeve + sleeve" assembly. For the outer sleeve riveting station in this automated assembly system, we have already constructed a Temporal Logic Expression (LTL). Next, we need to analyze its hierarchical subnet modeling, dynamic linkage mechanism, and global resource coordination mechanism to construct the Hierarchical Concurrent State Transition Network (HCSTN) for the corresponding embodiment.

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

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

[0122] 11) Top-level state and subnetting:

[0123] a) Extract top-level key state nodes: Based on the overall business process of the workstation, identify the top-level state set (in the example: Idle, Clamping, Pressing, Unclamping, Error), and construct a top-level state transition diagram accordingly, clarifying the legal transition paths between each state and the corresponding triggering conditions; the top-level transition diagram only reflects the macro process stage and does not include specific execution details, but it needs to annotate the related events with the underlying subnet.

[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 subnet corresponding to a composite state: Clamping subnet (lead screw motor extension / position logic), Pressing subnet (TOX riveting cylinder pressing / force value monitoring logic), Unclamping subnet (clamping reset action logic), Error subnet (fault handling logic); each composite state is represented as a node in HSTN, which contains the detailed state and transition of the subnet.

[0125] c) Define the activation / deactivation relationship between the top layer and subnets: During top-level migration, define when to activate or deactivate each subnet: When the top layer moves from Idle to Clamping, the Clamping subnet is activated; after the Clamping subnet is completed (broadcast completion event), the top layer moves from Clamping to Pressing, and then the Pressing subnet is activated; after the Pressing subnet is completed, the top layer moves from Pressing to Unclamping, and the Unclamping subnet is activated; when any subnet encounters an exception, the top layer migration enters the Error state and activates the Error subnet; after the Error subnet ends, it returns to the top layer Idle.

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

[0127] a) Identify atomic states and initial / final nodes: For each bottom-level subnet, identify the indivisible atomic states and determine the initial state and reachable final state: Clamping subnet: Idle, Extending, Done, Error, initial Idle, final Done or Error; Pressing subnet: Idle, Pressing, Done, Error, initial Idle, final Done or Error; Unclamping subnet: Idle, Unclamping, Done, initial Idle, final Done; Error subnet: FaultLatch, AlarmOn, ResetDone, initial FaultLatch, final ResetDone.

[0128] b) Extract internal triggering events / signals: For each subnet, list the types of events or signals required to trigger migration: sensor feedback, timeout signals, action command signals, reset command signals, etc.; clarify that these events will be used as migration triggering conditions or migration triggering prerequisites in HSTN; and broadcast the corresponding events to notify the top layer or other subnets during completed or abnormal migrations.

[0129] c) Define initial and completion flags: For each subnet, define the initial atomic state upon entry; define the completion event / signal to be emitted upon completion; define the exception event / signal to be emitted upon 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 with: source state → target state, triggering conditions (events, state dependencies, timeouts, etc.), resource request or release annotations, and accompanying event outputs (broadcast after completion / abnormality).

[0132] b) Specify the source and target states, trigger conditions, resource requests / releases, and event outputs for each migration: For example, in the Clamping subnet: Source and target states: T1_ScrewExtendCmd: Idle→Extending, migration trigger condition (Guard) is receiving an extend command and resource availability, Req(R); no event output or visual requirement is marked "ClampingStarted"; trigger condition is: T2_ScrewPosSensor: Extending→Done, migration trigger condition is position sensor trigger, Rel(R), output "ClampDone"; resource request / release is: T3_Timeout: Extending→Error, migration trigger condition is timeout signal, Rel(R), output "ClampTimeout"; event output is: T4_Reset: Error / Done→Idle, migration trigger condition is reset command, no resource request, preparing for the next loop. Migration for other subnets is defined similarly.

[0133] 14) Establish the linkage between the top-level network and subnets:

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

[0135] b) Add a completion event pre-processing to the top-level transition: Add a trigger pre-processing annotation to the top-level state transition edge.

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

[0137] c) Add top-level availability dependency in subnet initiation migration: Add a dependency on the top-level state availability or top-level event to the migration trigger conditions of the first migration within a subnet (migration starting from the Idle state) or a critical initiation migration: for example, add "the top-level is currently in the Pressing composite state" or "received a PressStart event broadcast from the top-level" to the migration trigger conditions of the PressCmd migration of the Pressing subnet; ensure that the subnet is only activated after the top-level enters the corresponding stage. Define a unified cross-layer / cross-subnet event identifier and broadcast it immediately when the subnet migration is triggered; the migration trigger conditions of the top-level and other subnets can detect this event in the same macrostep to achieve dynamic linkage.

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

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

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

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

[0142] d) Establish a resource token and event broadcast channel between the top layer and the subnet to ensure that the two work together and meet the 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, realizing clear visualization of the macroscopic process flow and accurate depiction of the microscopic equipment actions. 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 HSTN model.

[0144] The specific process for constructing the 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 at the workstation, including key states such as "Idle", "Clamping", "ClampedDone", and "Error"; Pressing subnet: responsible for performing pressing operations on clamped parts, including states such as "Ready / Idle", "Pressing", "PressDone", and "Error".

[0147] b) Clarify the sequence and mutual exclusion of actions: Sequence: The "start riveting" migration of the riveting subnet can only be triggered when the clamping subnet completes "clamping" and enters the ready state; Mutual exclusion: During the "riveting" state of the riveting subnet, the clamping subnet must not perform actions such as "releasing clamping" or re-clamping, and must remain locked; Similarly, after the clamping subnet has just occupied the fixture, the riveting subnet should not be started before the actual clamping is completed.

[0148] c) List the triggering and suppressing conditions: Example of triggering condition: The clamping completion migration output event (such as ClampDone) enables the "Start Riveting" migration of the riveting subnet; Example of suppressing condition: When the riveting subnet is in the "Riveting" state or has acquired riveting resources, the "Release Clive" or "Re-clamp" migration of the clamping subnet must be locked until the riveting is completed and the "PressDone" or "PressError" event is broadcast.

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

[0150] a) Specify event outputs for critical transitions: Clamping Subnet: "Clamping Complete" transition (Clamping→Done state): Output event ClampDone; "Clamping Error" transition (Clamping→Error): Output event ClampError; "Release or Reset" transition (Error / Done→Idle): May output ClampResetDone as needed, preparing for the next round of clamping or other subnet actions. Pressing Subnet: "Start Pressing" transition (Idle / Ready→Pressing): May output event PressStart; "Pressing Complete" transition (Pressing→Done): Output event PressDone; "Pressing Error" transition (Pressing→Error): Output event PressError; "Reset" transition (Error / Done→Idle): May output PressResetDone, used to notify the clamping subnet, etc., to enter the next cycle.

[0151] b) Declare sensitivity to the event in the target subnet migration trigger conditions: The migration trigger condition for the "start clamping" migration of the clamped subnet is: declare that the ClampDone event (i.e. clamping is complete) must be received and the resource token is available; The guard condition for the "release clamping" or "next clamping" migration of the clamped subnet is: declare that the PressDone or PressError event must be received and the current state is not in the clamping resource-occupying state; if an exception is received, the corresponding recovery logic can also be triggered.

[0152] c) Event Broadcasting Sequence: Upon triggering the "Clamp Complete" migration of the clamping subnet, the ClampDone event is broadcast immediately. Within the same macrostep, the "Start Riveting" migration of the riveting subnet to be evaluated detects this event and performs an availability check (e.g., resource token). Upon triggering the "Riveting Complete" migration of the riveting subnet, the PressDone event is broadcast, and the "Release Clamp" or "Prepare for Next Clamp" migration 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 condition / state dependencies:

[0154] a) Reference the clamped subnet state in the preconditions for triggering the clamped subnet migration: For example, the migration trigger condition for the "Start Clamping" migration is: "The clamped subnet is currently in the "Clamping Complete Ready" state and has received the ClampDone event and the global resource token is available;

[0155] b) Reference the crimped subnet status or resource occupancy in the clamping subnet migration trigger condition: For example, the migration trigger condition for "Release Clamp" migration is: the crimped subnet is not currently in the "Crimping" state and the PressDone or PressError event is received and the resource token has been returned after the crimping is completed or an error occurs;

[0156] c) Example of enabling conditions: "The 'Start Clamping' migration of the clamping subnet is triggered only when the clamping subnet has completed clamping, receives the ClampDone event, and the global resource token is available"; "The 'Release Clamping' or 'Next Clamping' migration of the clamping subnet is triggered only when the clamping subnet has completed clamping or exception handling, receives the PressDone / PressError event, and the resource token has been returned."

[0157] 24) Configure mutually exclusive or complementary resource locations:

[0158] a) Create a global resource token: When the model is initialized, a global resource token is created for the "clamping / riveting shared workstation or fixture resource" so that both parties can request to occupy it before the critical migration is triggered and release it after the migration is completed.

[0159] b) Declare token requests and releases on the relevant migrations:

[0160] Clamping subnet: The "Clamping Start" migration (Idle→Clamping) requests one resource token; at this time, resources are occupied, preventing the clamping subnet from occupying them simultaneously; the "Clamping Complete" migration (Clamping→Done) or the "Clamping Error" migration (Clamping→Error) releases the token; the ClampDone or ClampError event is output; the "Release Clamp / Reset" migration (Done / Error→Idle) usually does not request resources again, and only occurs after receiving the clamping complete event;

[0161] The Riveting subnet: The "Start Riveting" transition (Idle→Pressing) requests 1 resource token; it must be triggered when the ClampDone event is received and the token is available; the "Riveting Complete" transition (Pressing→Done) or the "Riveting Error" transition (Pressing→Error) releases the token; it outputs the PressDone or PressError event; the "Reset" transition (Done / Error→Idle) usually does not request resources, but only enters the idle state (Idle) after the corresponding event.

[0162] c) Mutual exclusion and suppression through holding / releasing: When the clamping subnet holds the resource token first and enters Clamping, the "start clamping" of the riveting subnet is suppressed because the token is unavailable; when clamping is completed or an exception occurs, the token is released and ClampDone or ClampError is broadcast. The riveting subnet holds the resource and starts clamping when it receives the event and the token is available; during clamping, the "release clamping" or "re-clamping" migration of the clamping subnet is suppressed; when clamping ends, the token is released and an event is broadcast. The clamping subnet holds the resource and performs release or the next round of clamping after receiving the event. If two subnets' critical migrations meet the triggering conditions simultaneously in the same macrostep and both request the token, the default conflict resolution strategy (such as first-come, first-served or priority) determines which one holds the token first, and the other waits.

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

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

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

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

[0167] b) Clearly define mutual exclusion requirements: The critical migrations for riveting in the TOX cylinder subnet (Pressing subnet) and the critical migrations for extension / clamping in the screw motor subnet (Clamping subnet) must each exclusively occupy this resource. The two cannot occupy it simultaneously to prevent mechanical interference or simulation misalignment. In addition, the resource must also be released during the exception handling process to avoid deadlock.

[0168] 32) Define the initialization of the resource repository and tokens:

[0169] a) Create a global place (e.g., identified as P_res_ClampPress) for the "Riveting Execution Resource" in the HCSTN model;

[0170] b) Based on the available capacity of the resource, place one token in the warehouse to indicate that the resource is initially free and available for use;

[0171] 33) Migration requests and release mapping extensions:

[0172] a) Add resource request and release parameters to the migration definitions for each subnet:

[0173] The screw motor subnet (Clamping subnet): The "Clamp Start" transition (e.g., T1_ClampCmd, Idle→Clamping) adds a request set Req(T1) containing one "Clamp Execution Resource" token; the "Clamp Complete" transition (e.g., T2_ClampPosSensor, Clamping→Done) or the "Timeout Fault" transition (T3_ClampTimeout, Clamping→Error) adds a release set Rel(T2, T3) at the end of execution, returning one token and outputting the events ClampDone or ClampTimeout respectively;

[0174] TOX Cylinder Subnet (Pressing Subnet): The "Start Riveting" migration (e.g., P1_PressCmd, Idle→Pressing) adds a request set Req(P1) containing one "Riveting Execution Resource" token; the "Riveting Complete" migration (e.g., P2_ForceOK, Pressing→Done) or the "Riveting Error" migration (e.g., P3_ForceNotOK, Pressing→Error) adds a release set Rel(P2, P3) to return one token and output the events 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 "start riveting" migration is "receive the clamping subnet completion event (ClampDone) and the global 'riveting execution resource' token is available"; the migration trigger condition for the ball screw motor "extend start" migration is "receive the top-level entry into the Clamping stage event and the global 'riveting execution resource' token is available"; by making the availability of resource tokens one of the prerequisites for migration trigger conditions, static constraints on resource contention are achieved.

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

[0177] a) Enable determination: When determining whether a migration t can be triggered, the following must be checked simultaneously:

[0178] i) The state / event triggering condition is met;

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

[0180] Migration t is marked as resource enabled only if both conditions are met.

[0181] b) Conflict detection: If multiple migrations simultaneously meet the state / event conditions, but the sum of their requests for the same resource exceeds the available tokens (in this example, if more than one migration simultaneously requests "riveting execution resource"), a resource conflict occurs.

[0182] c) Conflict resolution strategy: Select one migration to use the token and execute it according to a preset priority or a non-deterministic strategy. Other migrations will be re-evaluated in the next macrostep. For example, if the start migrations of the ball screw motor subnet and the TOX cylinder subnet both meet the state conditions and request resources in the same macrostep, then one of them will be executed according to the order or priority, and the other will be suppressed.

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

[0184] a) Deduct tokens at the start of migration: When a resource is enabled for migration t and is selected to trigger, the corresponding tokens are deducted from the global resource pool Cnt according to Req(t), indicating that the resource is occupied;

[0185] b) Return the token when the migration is complete or when entering an abnormal branch: When the release operation specified in the Rel(t) map occurs, the token is returned to the global repository to restore resource availability;

[0186] c) A new round of judgment is triggered after release: After the resource token is returned, migrations that were suppressed due to insufficient resources may be awakened, and availability will be reassessed in the same macrostep or the next macrostep.

[0187] d) Exception handling to ensure token release: If a TOX cylinder or ball screw motor subnet malfunctions during operation, the tokens still in use should be released uniformly during the entry migration of the malfunctioning subnet to prevent deadlock.

[0188] The above five steps together complete the definition, migration and resource mapping extension of the global resource repository, enable determination and conflict handling, as well as the token holding and release during the migration execution process, thereby realizing unified coordination and mutual exclusion access to shared resources in the HSTN model.

[0189] 41) Example of HCSTN formal parameters for riveting machine station:

[0190] For ease of verification, the HCSTN model of the "outer tube riveting station" in this embodiment can be formally defined using the following nine-tuple:

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

[0192] State set S: contains the top-level state and atomic and composite states of two subnets (Clamping and Pressing).

[0193]

[0194] Transfer set T: Take the key transfers,

[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 / target mapping F S ,F T :

[0199]

[0200] Global resource type set R:

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

[0202] Request / Release Mappings Req,Rel:

[0203]

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

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

[0206] The above nine-tuples rigorously characterize the state, migration, event, and resource model of the "outer tube riveting station" HSTN.

[0207] In summary, the HCSTN model comprehensively describes the dynamic behavior of the outer tube riveting machine. Through a hierarchical abstraction mechanism, dynamic linkage, and global resource coordination mechanism, it achieves efficient modeling of the riveting station control process. In this embodiment, the actions involved in the riveting station, such as cylinder extension and retraction, positioning detection, and gripper control, are effectively divided into multiple subnets, and dynamic activation and linkage are achieved through top-level scheduling. Resource mutual exclusion relationships are coordinated through a global resource token mechanism, ensuring 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 in multi-device collaboration and key resource competition scenarios, 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. 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.

Claims

1. A hierarchical concurrent state transition network method for digital twin virtual debugging, characterized in that, The method includes the following steps: Step 1: Hierarchical subnet modeling. Step 2: Construct a dynamic linkage mechanism. Step 3: Establish a global resource coordination mechanism; The specific process of step 1, hierarchical subnet modeling, is as follows: 11) Top-level state and subnetting: a) Starting from the overall business process, extract the key state nodes at the top level and construct a top-level state transition diagram; b) Divide the system into several underlying subnets according to function or actuator, with each subnet corresponding to a physical subprocess 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 completion status of the subnet in turn drives the next step of the top layer; 12) Extracting atomic states and events within a subnet: a) For each bottom-level subnet, identify the atomic states involved in that subnet and their corresponding state transition conditions; b) Extract the events or signals required to trigger migration within the subnet, in order to prepare for defining migration triggering conditions and resource requests within the subnet; c) Define the initial / end node for each subnet: that is, from which atomic state to start when entering the subnet, and what kind of completion flag to return or issue after execution; 13) Define the state transition structure within the subnet: a) Based on the extracted atomic states and events, draw a detailed state transition diagram for each subnet, including: state nodes and their behavioral semantics, transition edges and their starting conditions, and resource request or release annotations; b) Specify the source and target states, triggering conditions, and accompanying event outputs for each migration; 14) Establish the linkage between the top-level network and subnets: a) Map the "completion flag" of each subnet to the trigger event for the top-level migration; b) Add a triggering precondition to the top-level migration, requiring the existence of the completion event of the corresponding subnet or that the subnet has exited to the specified state; c) In the subnet startup migration, add "top-level status in place" or "top-level event received" as a triggering prerequisite to ensure that the subnet is only activated when the top level enters the corresponding stage; 15) Integrate to form a complete HCSTN hierarchical structure: a) In the overall HCSTN model, first retain the nodes and edges of the top-level state transition graph; b) Insert each subnet into the corresponding composite state, where the complete STD of the corresponding subnet is inside the composite state; c) Define the entry / exit mechanism for composite states: upon entry, activate the initial state in the subnet; upon exit, wait for the subnet to enter the end state and issue a completion event. d) Establish a resource token and event broadcast channel between the top layer and the subnet to ensure that the two work together and meet the resource mutual exclusion requirements.

2. The hierarchical concurrent state transition network method for digital twin virtual debugging according to claim 1, characterized in that, Step 2: Construct a dynamic linkage mechanism, as detailed below. 21) Identify concurrent subnets and linkage requirements: a) Identify the concurrent subnets in the model that need to cooperate or interlock with each other, and clarify the order of actions or mutual exclusion relationships between them; b) For each pair of subnets that need to be linked, list the triggering conditions and the corresponding suppression conditions. 22) Define a global event publishing-response mechanism. a) Specify event outputs for critical migrations in HSTN to notify other subnets; b) Declare sensitivity to the event in the migration triggering conditions of the target subnet to ensure synchronous activation within the same macrostep; c) When a certain migration condition is triggered, immediately broadcast the corresponding event globally. All migrations waiting for this event during the trigger will perform availability checks in parallel. 23) Establish cross-subnet condition / status dependencies: a) Reference the active state of subnet B in the preconditions for triggering migrations in subnet A, and vice versa, to form clear cross-subnet dependencies. b) Incorporate both "subnet B is in state s" and "receiving event E" into the triggering prerequisite of a certain migration in subnet A to achieve the static linkage of "only trigger when other subnets meet specific states and events". 24) Configure mutually exclusive or complementary resource positions: a) If two or more subnets need to mutually exclusive occupy the same resource during an action, create a global mutually exclusive shared resource (Place) for this resource in HCSTN, which contains the corresponding mutually exclusive tokens (Tokens). b) Declare a request (Req) for the position of this mutually exclusive token on the critical migrations of relevant subnets. After occupancy, it will automatically prevent similar migrations in other subnets. Return the token by releasing (Rel) when the action is completed. c) Through the occupancy / release of resource tokens, achieve mutual exclusion and linkage inhibition during the action. 25) Define synchronous migration groups: a) For multiple migrations that need to be strictly synchronously triggered, mark them as the same synchronous group. b) Or merge these migrations into a composite migration, set unified multi-source states and multi-target states to ensure that either all are triggered simultaneously or none are triggered. c) Bind the same synchronous event or cross-subnet state prerequisite in the preconditions for triggering all synchronous migrations to maintain the atomicity of the action.

3. The hierarchical concurrent state transition network method for digital twin virtual debugging according to claim 1, characterized in that, Step 3, Build a global resource coordination mechanism, specifically as follows: 31) Identify shared resources and mutual exclusion requirements: a) Determine all global resources that concurrent subnets in the system need to compete for, and clarify which subnets' access to the same resource should be mutually exclusive. 32) Define resource places and token initialization: a) Create corresponding shared resource places (Places) for each shared resource r (r ∈ R) in the HCSTN model, and place the corresponding number of tokens (Tokens) in the place according to the capacity of the resource. 33) Extend migration request and release mapping: a) Add in the definition of each migration t: Request set Req(t): Specify the resources and the number of their tokens to be occupied before triggering. Release set Rel(t): Specify the resources and the number of their tokens to be returned after triggering. b) Incorporate both "subnet B is in state s" and "receiving event E" into the triggering prerequisite of a certain migration in subnet A to achieve the static linkage of "only trigger when other subnets meet specific states and events". 34) Resource enabling determination and conflict resolution: a) When judging whether migration t can be triggered, simultaneously check that its status / event conditions and all (r, n) ∈ Req(t) satisfy Cnt(r) ≥ n. If multiple migrations compete for the same resource and there are insufficient available tokens, select one of the migrations to occupy the token according to the preset priority or non-deterministic strategy, and the others will be re-judged in the next macro step. 35) Migration execution and token synchronous update: a) When the migration begins, the corresponding token is deducted from the global resource map Cnt based on Req(t).

4. The hierarchical concurrent state transition network method for digital twin virtual debugging according to claim 1, characterized in that, The method also Includes the following steps, Step 4: Construct the formal model of HCSTN. 41) An HSTN model is defined as a nine-tuple: It is a set of states, containing atomic states and composite states, represented by a relation. To represent the hierarchical containment relationship of states: mean It is a composite state direct substates, Each state must be a composite state. Each composite state is a tree node, and its set of child states forms a subnet. A subset of atomic states It is a subset of composite states. It is a set of migrations, each migration Connecting several states as a source to several states as a destination, two functions are defined for a unified representation. and The source state set and target state set for the migration are given respectively, where the source state set is... This represents the set of states that need to be left to trigger the migration, and the target state set. This represents the set of states entered after the migration is complete. It is a collection of events, assuming that the events are triggered or perceived by migration, and a function is defined. This represents the set of events generated when a migration is triggered. It can contain at most one event, corresponding to a single event identifier accompanying the migration, and each migration also has a guard condition. It is a logical expression about the current state configuration and events. If the migration is sensitive to a certain event, then that event appears in the guard condition. It is a global collection of resource types, each resource With capacity function ,definition , Map each migration to its requested and released resources and quantities, when Time indicates unnecessary ; Define release, It is the initial set of active states, which includes the initial state of the top-level network and the initial sub-states of each concurrent region. It is assumed that for each composite state... , At most contains A substate, representing entering The initial activator state at that time, 42) Semantically, an HSTN configuration is determined by... It means that among them It is the set of currently active atomic states, constituting a valid cross-section at each level. Provide the current available quantity of each resource and the initial configuration. satisfy: Includes All top-level atomic states, and For all ,migrate In configuration The following is enabled if and only if: a) State premise: All source states are currently active during migration; b) Escort conditions: It is true under the current global state / event, including when the event is satisfied and other subnet state dependencies are satisfied; c) Resource prerequisites: For all ,have The required resources are no less than the required amount of available resources; 43) When migrating When a fire occurs, the system state will change as follows: a) New set of active states That is, the atomic states of the source state set are exited, and the atomic states of the target state set are entered, if If a substate contains a certain composite state, it means that the composite state has been entered; conversely, the same applies to exiting. This step requires recursively processing the logic of entering / exiting the hierarchy. 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 ,renew For each ,renew If the model's state period needs to represent "resource holding," then resource release will be delayed until the corresponding release action transition. c) Event Generation: After the migration occurs, its accompanying event set Events are placed into a queue for processing, and are then processed by other transfer senses within the same macrostep. The processing of this queue follows broadcast semantics—that is… The event affects all migrations All are visible. When the macrostep ends, external events are cleared, and only state conditions that may continue to be valid are retained.

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

6. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by the processor, the computer instructions implement a hierarchical concurrent state transition network method for digital twin virtual debugging as described in any one of claims 1-4.

Images