A breakpoint restart method and device of a simulation system under a platform and model separation architecture

Abstract

The embodiment of the application provides a breakpoint restart method and device of a simulation system under a platform and model separation architecture, and relates to the technical field of simulation, wherein the method comprises the following steps: constructing a simulation platform and a plurality of simulation models through an interface, constructing an event scheduling queue after obtaining breakpoint configuration parameters, distributing events according to queue order and monitoring trigger conditions; pausing distribution when the conditions are met, determining a target model and generating context information containing a current simulation time, an event snapshot and a state fingerprint and storing the context information in a storage area; receiving a save request issued to the target model, and outputting state data of the model to an independent storage area; persisting the event snapshot into a queue snapshot file, and forming an index record in association with the state data; receiving a load context and index according to the identification, issuing a recovery request to the corresponding model to load the state data, and continuing and performing a consistency check after completion. Through selective breakpoints and decoupled storage, the debugging continuity and checkpoint reusability are improved.

Description

Technical Field

[0001] This invention relates to the field of simulation technology, and in particular to a method and apparatus for restarting a simulation system with a platform and model separation architecture. Background Technology

[0002] As the complexity of simulation systems continues to increase, effectively separating the simulation platform from the simulation model has become one of the core challenges in the architecture design of large-scale distributed simulation systems. In this architecture, the simulation platform should be responsible for infrastructure services such as time progression, event scheduling, communication management, and resource allocation, while simulation models from various domains should be accessed as independent computing units through standardized interfaces. However, existing simulation systems typically highly couple the infrastructure functions of the simulation platform with the business model, storing state data in a mixed manner, making it difficult for models to iterate and reuse independently. This coupled architecture faces the following technical problems when implementing breakpoint saving and restarting in the simulation system: 1. Breakpoint triggering typically employs a global pause approach, halting the entire simulation system. In multi-model collaborative simulation scenarios, when a user only needs to debug or inspect a specific model, other unrelated models are forced to stop, leading to wasted simulation resources and decreased overall efficiency. For simulation tasks running continuously for extended periods, this global pause severely impacts the continuity of simulation progress.

[0003] 2. Coupled storage of platform and model states. Existing checkpointing techniques typically save the state of the simulation platform and each model as a whole in snapshots, resulting in a massive amount of checkpoint data. Furthermore, after a model is updated or replaced, old checkpoints cannot be reused. This severely restricts the efficiency of independent iterative development of the model.

[0004] 3. Lack of effective guarantees for data consistency after breakpoint recovery. In model-level breakpoint scenarios, other models continue to run and generate new data while the target model is paused. Upon recovery, there is a time discrepancy between the state of the target model and the states of other models. Existing technologies lack effective mechanisms to handle this "time misalignment." Furthermore, causal dependencies between models may be disrupted after recovery, and existing technologies lack verification methods for this. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a method for restarting a simulation system with a platform and model separation architecture, to solve the technical problems of simulation interruption caused by global pause when an interruption point is triggered, and redundant and unreusable checkpoints caused by the coupling of platform and model states in the prior art. The method includes: A simulation platform and multiple simulation models are provided. The simulation platform and the simulation models interact through a standardized interface. The simulation platform manages the event scheduling queue, logical clock, and event distribution. The simulation models independently encapsulate state data and simulation logic. Obtain breakpoint configuration parameters, construct an event scheduling queue on the simulation platform, distribute simulation events to each simulation model according to the order of the event scheduling queue, and monitor whether the breakpoint triggering conditions are met during the distribution process. The breakpoint configuration parameters include breakpoint identifier and breakpoint triggering conditions. When the breakpoint triggering condition is met, the distribution of subsequent simulation events to the simulation model is paused, the target simulation model is determined and breakpoint context information is generated, and the breakpoint identifier is stored in the breakpoint storage area. The breakpoint context information includes the current simulation time, a snapshot of the event data of the remaining simulation events that have not yet been distributed in the event scheduling queue, and the state data fingerprint of the target simulation model at the breakpoint time. When a breakpoint save command is received, a state save request is sent to the target simulation model according to the breakpoint context information. The target simulation model outputs its own state data to a model state storage area independent of the simulation platform according to the state save request. The event data snapshot is persisted as an event queue snapshot file, and the event queue snapshot file and the status data are associated and stored through the breakpoint identifier to form a breakpoint index record; When a breakpoint restart command is received, the corresponding breakpoint context information and breakpoint index record are loaded according to the breakpoint identifier in the breakpoint restart command. The state of the event scheduling queue is restored according to the event queue snapshot file. A state recovery request is sent to the corresponding simulation model according to the breakpoint index record to trigger each simulation model to load the state data. After the recovery is completed, the simulation continues to run and a consistency check is performed.

[0006] This invention also provides a breakpoint restart device for a simulation system with a platform and model separation architecture, to solve the technical problems of simulation interruption caused by global pause when a breakpoint is triggered, and redundant and unreusable checkpoints due to platform and model state coupling in the prior art. The device includes: The simulation platform provides a module for providing a simulation platform and multiple simulation models. The simulation platform and the simulation models interact through a standardized interface. The simulation platform manages the event scheduling queue, logical clock, and event distribution. The simulation models independently encapsulate state data and simulation logic. The distribution module is used to obtain breakpoint configuration parameters, which include breakpoint identifiers and breakpoint triggering conditions. It constructs an event scheduling queue on the simulation platform, distributes simulation events to each simulation model according to the order of the event scheduling queue, and monitors whether the breakpoint triggering conditions are met during the distribution process. The breakpoint context generation module is used to pause the distribution of subsequent simulation events to the simulation model when the breakpoint triggering condition is met, determine the target simulation model and generate breakpoint context information, and store it in the breakpoint storage area with the breakpoint identifier as the key. The breakpoint context information includes the current simulation time, a snapshot of the event data of the remaining simulation events that have not yet been distributed in the event scheduling queue, and the state data fingerprint of the target simulation model at the breakpoint time. The state saving management module is used to send a state saving request to the target simulation model according to the breakpoint context information when a breakpoint saving instruction is received, so that the target simulation model can output its own state data to a model state storage area independent of the simulation platform according to the state saving request. The breakpoint index record generation module is used to persist the event data snapshot as an event queue snapshot file, and associate the event queue snapshot file with the status data through the breakpoint identifier to form a breakpoint index record; The breakpoint restart management module is used to, when a breakpoint restart instruction is received, load the corresponding breakpoint context information and breakpoint index record according to the breakpoint identifier in the breakpoint restart instruction, restore the state of the event scheduling queue according to the event queue snapshot file, send a state recovery request to the corresponding simulation model according to the breakpoint index record to trigger each simulation model to load the state data, and continue to drive the simulation to run and perform consistency verification after the recovery is completed.

[0007] Compared with the prior art, the beneficial effects that at least one technical solution adopted in the embodiments of this specification can achieve include at least: By selectively pausing simulation event distribution when a breakpoint is triggered and storing event queue snapshots separately from model state data, the technical problems of global pause causing simulation continuity interruption and platform-model state coupling leading to checkpoint redundancy and non-reusability in existing technologies are solved, thus improving the flexibility of simulation debugging and the reusability of checkpoint data. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a flowchart of a breakpoint restart method for a simulation system with a platform and model separation architecture, provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of the data flow of a simulation platform and simulation model for implementing the above-described breakpoint restart method, provided by an embodiment of the present invention; Figure 3 This is a structural block diagram of a breakpoint restart device for a simulation system with a platform and model separation architecture, provided in an embodiment of the present invention. Detailed Implementation

[0010] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0011] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] In this specification, to clearly distinguish between user operations and system execution flow, the "breakpoint save command" triggered by the user through the interactive interface is defined as an instantaneous operation initiated by the user; the entire process of saving state data, persisting event queue snapshots, and generating index records in response to this command by the simulation platform is collectively referred to as the "state save phase" or "state persistence phase." Similarly, the "breakpoint restart command" refers to a recovery operation initiated by the user through the interactive interface, while the "breakpoint recovery phase" refers to the complete process of the simulation platform executing state loading, event queue reconstruction, and consistency verification.

[0013] In this embodiment of the invention, a method for restarting a simulation system with a platform and model separation architecture is provided, such as... Figure 1 As shown, the method includes: Step S101: Provide a simulation platform and multiple simulation models. The simulation platform and the simulation models interact through a standardized interface. The simulation platform manages the event scheduling queue, logical clock, and event distribution. The simulation models independently encapsulate state data and simulation logic. Step S102: Obtain breakpoint configuration parameters, construct an event scheduling queue on the simulation platform, distribute simulation events to each simulation model according to the order of the event scheduling queue, and monitor whether the breakpoint triggering conditions are met during the distribution process. The breakpoint configuration parameters include breakpoint identifier and breakpoint triggering conditions. Step S103: When the breakpoint triggering condition is met, pause the distribution of subsequent simulation events to the simulation model, determine the target simulation model and generate breakpoint context information, and store it in the breakpoint storage area with the breakpoint identifier as the key. The breakpoint context information includes the current simulation time, the event data snapshot of the remaining simulation events that have not yet been distributed in the event scheduling queue, and the state data fingerprint of the target simulation model at the breakpoint time. Step S104: When a breakpoint save instruction is received, a state save request is sent to the target simulation model according to the breakpoint context information. The target simulation model outputs its own state data to a model state storage area independent of the simulation platform according to the state save request. Step S105: Persist the event data snapshot as an event queue snapshot file, and associate the event queue snapshot file with the status data through the breakpoint identifier to form a breakpoint index record; Step S106: When a breakpoint restart instruction is received, the corresponding breakpoint context information and breakpoint index record are loaded according to the breakpoint identifier in the breakpoint restart instruction. The state of the event scheduling queue is restored according to the event queue snapshot file. A state recovery request is sent to the corresponding simulation model according to the breakpoint index record to trigger each simulation model to load the state data. After the recovery is completed, the simulation continues to run and consistency verification is performed.

[0014] In practice, the following steps are used to pause the distribution of subsequent simulation events to the simulation model: The breakpoint scope information is obtained from the breakpoint configuration parameters. This breakpoint scope information indicates whether the event dispatcher of the simulation platform should perform global or local filtering when the breakpoint is triggered. When the breakpoint scope information indicates global filtering, the event dispatcher intercepts all simulation events distributed to the target simulation model after the breakpoint is triggered; the target simulation model is all simulation models. When the breakpoint scope information indicates local filtering, the simulation platform obtains the target simulation model identifier from the breakpoint configuration parameters and identifies the simulation model corresponding to the target simulation model. The event dispatcher only intercepts events after the breakpoint is triggered. Simulation events are sent to the simulation model corresponding to the target simulation model identifier, and simulation events are continuously output to other simulation models. The logic clock of the simulation platform continues to advance after the breakpoint is triggered. The simulation events intercepted by the event dispatcher are stored in the event buffer and the buffer event count is recorded. When the buffer event count reaches a preset threshold, the simulation platform suspends the distribution of subsequent simulation events to the adjacent downstream models of the target simulation model and outputs a buffer overflow alarm. When a breakpoint restart command is received, the event dispatcher re-injects the simulation events temporarily stored in the event buffer into the event scheduling queue according to the original timestamp order of the simulation events.

[0015] In practice, the following steps are used to generate breakpoint context information: The simulation platform obtains the real-time status data of the target simulation model through a standardized interface, performs a hash operation on the real-time status data to generate a status data fingerprint, obtains the current model version number of the target simulation model, and associates the status data fingerprint and the model version number in the breakpoint context information. In response to a breakpoint restart command but before sending a status recovery request to the target simulation model, the simulation platform loads the breakpoint context information from the breakpoint storage area, extracts the model version number from the breakpoint context information, queries the target simulation model for the current model version number, and compares the queried current model version number with the model version number in the breakpoint context information. If the comparison result matches, status recovery is allowed, and a status recovery request is sent to the target simulation model. If the comparison result does not match, status recovery is rejected, and a model version mismatch alarm is output.

[0016] In specific implementation, the following steps are used to send a state save request to the target simulation model based on the breakpoint context information: After the simulation platform sends a state save request to the target simulation model, it starts an asynchronous save timer and records the simulation models that have sent state save requests but have not yet returned save confirmation messages in the pending confirmation list. If the pending confirmation list is empty before the asynchronous save timer expires, it is confirmed that all target simulation models have completed state saving. If the pending confirmation list is not empty after the asynchronous save timer expires, the simulation platform only resends the state save request to the simulation models in the pending confirmation list and records a save exception log, which includes the timeout model identifier and the number of resends. If the pending confirmation list is still not empty after resending, the simulation platform marks the breakpoint index record as partially completed and continues to execute the subsequent breakpoint save process.

[0017] In specific implementation, the target simulation model outputs its own state data to a model state storage area independent of the simulation platform according to the state saving request through the following steps: When the simulation platform issues the state save request, it instructs the target simulation model to either save as a baseline save or an incremental save. If the target simulation model has not saved state data before the breakpoint time corresponding to the breakpoint identifier, the target simulation model performs the baseline save, outputting its own state data as a baseline file to the model state storage area. If the target simulation model has saved state data before the breakpoint time corresponding to the breakpoint identifier, the target simulation model performs the incremental save, obtaining the binary difference data between the current state data and the latest saved state data, and outputting the binary difference data as an incremental file to the model state storage area. The breakpoint index record contains dependency order information between the incremental file and the baseline file. When the simulation platform responds to the breakpoint restart instruction and loads the state data, it issues the state recovery request to the target simulation model according to the dependency order information in the breakpoint index record, so that the target simulation model loads the baseline file and the incremental file sequentially according to the dependency order to reconstruct the state data.

[0018] In practice, the following steps are used to load the corresponding breakpoint context information: The process involves: obtaining the consumption relationships between the event input data and the upstream event output data of each simulation event in the event scheduling queue that has not yet been distributed, as found in the breakpoint context information; constructing a data dependency graph based on these consumption relationships, wherein each directed edge in the data dependency graph is associated with and stores the state data fingerprint of the target simulation model corresponding to the upstream event at the breakpoint time; after the simulation platform restores the state of the event scheduling queue based on the event queue snapshot file, it traverses each directed edge in the data dependency graph to obtain the real-time state data fingerprint of the target simulation model corresponding to each upstream event at the current time, and then associating the real-time state data fingerprint with the directed edge. The fingerprints of the breakpoint state data stored in the association are compared. If all directed edges match, the simulation events in the event scheduling queue are executed in the original order. If there are directed edges that do not match, the downstream simulation events pointed to by the directed edges are located, and the upstream simulation events that generate the data dependency are identified by tracing upstream along the data dependency graph. The upstream simulation events and all their downstream simulation events are moved to the head of the event scheduling queue and a forced execution mark is added. The events are executed in the order after the move, and a conflict diagnosis report is output. The conflict diagnosis report includes the identification information of the directed edges that do not match and a list of the identifications of the affected simulation events.

[0019] In specific implementation, the following steps are used to send a state recovery request to the corresponding simulation model based on the breakpoint index record, thereby triggering each simulation model to load the state data: Before issuing a state recovery request to the corresponding simulation model, the simulation platform sends a state existence query request to each simulation model through a standardized interface. This state existence query request carries the breakpoint identifier. The simulation platform receives state existence query responses from each simulation model through the standardized interface. These responses contain a Boolean value indicating whether the current simulation model stores a state file corresponding to the breakpoint identifier. The simulation platform marks simulation models with negative Boolean values ​​as cold start models and those with positive Boolean values ​​as recovery models. The simulation platform issues an initialization command to the cold start model, which includes the current simulation time from the breakpoint context information, so that the cold start model starts execution from its initial state and progresses to the current simulation time. The simulation platform issues the state recovery request to the recovery model, so that the recovery model loads the state data. After the cold start model completes initialization and the recovery model completes state data loading, the simulation platform sends a logical time synchronization signal to both the cold start model and the recovery model, so that they align at the current simulation time and jointly advance the simulation.

[0020] In practice, the following steps are used to ensure that the simulation continues to run after recovery: If the breakpoint scope information is global filtering, the simulation platform resumes event distribution synchronously to all simulation models starting from the current simulation time. If the breakpoint scope information is local filtering, the simulation platform obtains the time offset between the current simulation time of the simulation platform and the breakpoint time in the breakpoint context information; it adds the time offset to the event execution time of each simulation event temporarily stored in the event buffer, aligning the event execution time of each simulation event with the current simulation time; it sends time synchronization information, which includes the current simulation time, to the target simulation model, resumes event distribution to the target simulation model, and other simulation models continue to execute events received during continuous operation after the breakpoint is triggered; and it re-injects the simulation events with aligned timestamps into the event scheduling queue.

[0021] In practice, consistency verification is performed through the following steps: After completing the state recovery of all simulation models and distributing recovery events to all simulation models, the simulation platform starts a consistency check timer. Before the consistency check timer expires, the simulation platform intercepts output events sent by the target simulation model to other simulation models, extracts the current state data carried in the output events, performs a hash operation on the current state data to generate a current state data fingerprint, and compares the current state data fingerprint with the breakpoint state data fingerprint stored in the breakpoint context information. If the comparison matches, the simulation platform allows the output event to proceed; if the comparison does not match, the simulation platform suspends event distribution for all simulation models, outputs a consistency alarm, and provides the user with two recovery options: rollback to the breakpoint or continue forward. The consistency alarm includes the fingerprint information of the inconsistency and the corresponding simulation model identifier.

[0022] I. System Architecture like Figure 2 As shown, the simulation system of this embodiment includes a user interface, a simulation platform, and multiple simulation models. The simulation platform interacts with each simulation model through a standardized interface. In this embodiment, the standardized interface between the simulation platform and each simulation model adopts a lightweight communication protocol based on JSON-RPC or Protocol Buffers, which supports both synchronous calls and asynchronous callbacks. The standardized interface includes at least: (1) Event distribution interface, used by the simulation platform to distribute simulation events to a specified simulation model; (2) State saving interface, used by the simulation platform to request the simulation model to save the current state data; (3) State recovery interface, used by the simulation platform to request the simulation model to load specified state data; (4) Status fingerprint query interface, used by the simulation platform to obtain the hash fingerprint of the current state of the simulation model.

[0023] The simulation platform internally includes an event scheduling queue, an event dispatcher, a breakpoint storage area, a state saving management unit, a state recovery management unit, and a consistency verification unit. The event scheduling queue adopts a priority queue-based data structure, sorted according to the execution timestamps of simulation events. The event dispatcher runs as an independent thread, retrieving the head event from the event scheduling queue in an event-driven manner and dispatching it to the corresponding simulation model.

[0024] Each simulation model connects to the simulation platform through the standardized interface described above. Each simulation model independently encapsulates its own state data (including internal register values, memory contents, program counter, etc.), simulation logic (including model calculation functions and state transition functions), and model version information. This architecture minimizes the coupling between the platform and the model, allowing models to be developed, updated, and replaced independently without affecting the platform's infrastructure functionality.

[0025] The user interface is used to receive user input of breakpoint configuration parameters, breakpoint save commands, and breakpoint restart commands, and to display the simulation running status and various alarm information to the user.

[0026] The simulation platform is the main body for executing the breakpoint restart method. It contains an event scheduling queue, an event dispatcher, a breakpoint storage area, a state saving management unit, a state recovery management unit, a model state storage area, and a consistency verification unit.

[0027] The event scheduling queue stores simulation events to be executed by each simulation model. Each simulation event's data structure includes at least an event identifier, a target model identifier, an event execution time, and event input data. The event scheduling queue is sorted by event execution time, and the event dispatcher retrieves and distributes them sequentially to the corresponding simulation models.

[0028] The breakpoint storage area stores the breakpoint context information generated when a breakpoint is triggered. The model state storage area is independent of the simulation platform's storage space and is used to store the state data output by each simulation model at the breakpoint moment. The consistency verification unit is used to intercept and verify the model output events after the breakpoint is resumed.

[0029] Multiple simulation models, including simulation model A, simulation model B, and so on up to simulation model N, are used. Each simulation model connects to the simulation platform through a standardized interface, and each simulation model independently encapsulates its own state data, simulation logic, and model version information.

[0030] It should be noted that all interactions between the simulation platform and each simulation model are completed through standardized interfaces, including event distribution, the issuance and confirmation of state saving requests, the issuance and confirmation of state recovery requests, as well as the acquisition of state data fingerprints and the query of model version numbers.

[0031] II. Breakpoint Configuration Users send breakpoint configuration commands to the simulation platform through the user interface. The simulation platform obtains the breakpoint configuration parameters, which include the breakpoint identifier and breakpoint trigger conditions. The breakpoint identifier is used to uniquely identify the breakpoint in subsequent save, query, and restart operations. The breakpoint trigger conditions define the conditions under which the breakpoint is activated; in this implementation, multiple trigger types are supported: The simulation time has reached a preset time threshold. For example, the user sets a breakpoint to be triggered when the simulation time reaches 100 seconds, and the event dispatcher pauses event dispatching when the simulation time reaches that point.

[0032] The number of events distributed in the event scheduling queue has reached a preset threshold. For example, the user sets a breakpoint to be triggered when the simulation platform has distributed 1000 simulation events to each simulation model.

[0033] Specify the simulation model to handle a specified type of event. For example, the user sets a breakpoint to be triggered when simulation model A completes a mechanical calculation event, and the event dispatcher pauses dispatching after detecting that the model has reported an event completion signal.

[0034] External trigger signals. For example, if a user manually clicks the "Trigger Breakpoint" button through the user interface, the simulation platform immediately pauses event dispatch.

[0035] Users can choose one or a combination of multiple trigger conditions according to their simulation debugging needs. The specific thresholds for the above trigger conditions are configured by the user through the user interface, and the simulation platform stores the configuration parameters in the breakpoint storage area.

[0036] After obtaining the breakpoint configuration parameters, the simulation platform constructs an event scheduling queue. The event scheduling queue is the core data structure of the simulation platform, used to manage all simulation events to be executed during the simulation process. After processing the current event, each simulation model can submit new events to the simulation platform through the event dispatch interface, and these new events are inserted into the appropriate positions in the event scheduling queue.

[0037] Simultaneously, the simulation platform also acquires breakpoint scope information, which indicates whether the event dispatcher performs global or local filtering when the breakpoint is triggered. Global filtering means that simulation events dispatched to all simulation models are intercepted after the breakpoint is triggered, i.e., the progress of the entire simulation system is paused, suitable for global state checks and system-level debugging. Local filtering means that events sent to a specific simulation model are intercepted after the breakpoint is triggered, suitable for fine-grained debugging of a single model.

[0038] III. Simulation Execution and Breakpoint Triggering The simulation platform retrieves each simulation event sequentially from the event scheduling queue and distributes them to the corresponding simulation model. During the distribution process, the event dispatcher continuously monitors whether the current simulation state meets the breakpoint triggering conditions.

[0039] When the breakpoint triggering condition is met, the event dispatcher pauses the dispatch of subsequent simulation events to the simulation model and executes corresponding actions according to the pre-configured breakpoint scope information.

[0040] If the breakpoint scope information is global filtering, the event dispatcher will intercept all simulation events distributed to all simulation models after the breakpoint is triggered. At this time, all models will stop receiving new events, and the entire simulation system will pause.

[0041] If the breakpoint scope information is local filtering, the simulation platform obtains the target simulation model identifier from the breakpoint configuration parameters and identifies the simulation model corresponding to that identifier as the target simulation model. After the breakpoint is triggered, the event dispatcher only intercepts events destined for that target simulation model and continuously outputs simulation events destined for other simulation models. During this process, the simulation platform's logical clock continues to advance after the breakpoint is triggered, meaning that other simulation models continue to run according to their original scheduling rhythm, unaffected by the breakpoint.

[0042] In local filtering mode, the event dispatcher stores intercepted simulation events in the event buffer and records the buffer event count. As the breakpoint duration increases, the number of events accumulated in the event buffer gradually rises. When the buffer event count reaches a preset threshold, the simulation platform pauses the distribution of subsequent simulation events to adjacent downstream models of the target simulation model and outputs a buffer overflow alarm.

[0043] In a preferred embodiment of this implementation, the event buffer is implemented using a circular buffer data structure, the capacity of which can be configured by the user, with a default value of 1024 events. When the event dispatcher writes intercepted simulation events into the buffer, it simultaneously updates the buffer event counter.

[0044] The preset threshold is set to 80% of the buffer capacity. When the cached event count reaches this preset threshold, the simulation platform performs the following overflow protection operation: (1) The event dispatcher pauses the dispatch of subsequent simulation events to the adjacent downstream models of the target simulation model to prevent events from accumulating in the downstream models during the pause of the target model and causing cascading overflow; (2) The simulation platform outputs a buffer overflow alarm through the user interface. The alarm includes the current number of cached events, the target model identifier, and a list of downstream model identifiers that have been suspended from distribution. (3) When the cached event count drops below 50% of the preset threshold, the simulation platform automatically resumes distributing events to adjacent downstream models.

[0045] When a breakpoint restart command is received and the breakpoint scope information indicates local filtering, the event dispatcher retrieves the simulation events temporarily stored in the event buffer one by one according to the original timestamp order of the simulation events and re-injects them into the event scheduling queue. The event scheduling queue is then reordered according to the timestamp of each event and continues to distribute them.

[0046] The write and read pointers of the circular buffer are updated atomically to support the event dispatcher to continuously write cached events after a breakpoint is triggered, while the same thread reads them sequentially when the breakpoint is resumed, without the need for additional locking mechanisms, thus avoiding the impact on the event dispatch performance of the simulation platform.

[0047] This mechanism can prevent memory overflow problems caused by the continuous backlog of events during the pause of the target simulation model, as well as instantaneous overload caused by the large number of events during the recovery.

[0048] For example, in a specific application scenario, if the number of events accumulated in the event cache reaches a preset threshold of 1,000 during the pause of the target simulation model, the simulation platform will pause the distribution of events to its downstream models and output an alarm. Users can decide whether to resume the simulation in advance or adjust the caching strategy based on the alarm information.

[0049] IV. Generating Breakpoint Context Information After a breakpoint is triggered, the simulation platform generates breakpoint context information and stores it in the breakpoint storage area using the breakpoint identifier as the key. The breakpoint context information includes the current simulation time, a snapshot of the event data of the remaining simulation events that have not yet been dispatched in the event scheduling queue, and the state data fingerprint of the target simulation model at the breakpoint moment.

[0050] The state data fingerprint is generated as follows: The simulation platform acquires real-time state data of the target simulation model through a standardized interface, performs a hash operation on this real-time state data, and generates a state data fingerprint. The hash operation can use algorithms such as MD5 or SHA-256; this implementation does not limit the specific algorithm used. The state data fingerprint is used to verify the consistency of the model state during subsequent state recovery; that is, by comparing whether the hash values ​​of the model states before and after recovery are consistent, it is determined whether the state data has been correctly recovered.

[0051] In one implementation, the simulation platform also obtains the current model version number of the target simulation model and associates the state data fingerprint with the model version number, storing it in the breakpoint context information. The model version number is used to verify whether the model has undergone a version change during recovery. The specific verification process will be described in detail in the breakpoint recovery phase below.

[0052] In addition, the breakpoint context information also includes the consumption relationships between the input data of each simulation event in the event scheduling queue and the output data of the upstream events. These consumption relationships are used to construct a data dependency graph during recovery to verify whether the execution order of events after breakpoint recovery conforms to causal logic. The specific usage of the data dependency graph will be described in detail in the consistency verification section below.

[0053] In this implementation, the model version number is used to perform version compatibility checks during breakpoint recovery. When a user triggers a breakpoint restart but before the simulation platform sends a state recovery request to the target simulation model, the simulation platform loads the breakpoint context information from the breakpoint storage area, extracts the stored model version number, and queries the target simulation model for the current model version number, comparing the two. If they match, it indicates that the state data saved at the breakpoint is compatible with the current model version, and state recovery is allowed. If they do not match, it indicates that the model has been updated after the breakpoint, and the old state data may be incompatible with the logic of the new version model. In this case, the simulation platform refuses to perform state recovery and outputs a model version mismatch alarm, prompting the user to confirm the model change and reset the breakpoint.

[0054] V. Breakpoint Saving Users send breakpoint save commands to the simulation platform through the user interface. Upon receiving the breakpoint save command, the simulation platform issues a state save request to the target simulation model based on the breakpoint context information. The target simulation model then outputs its own state data to a model state storage area independent of the simulation platform based on this request.

[0055] In one implementation, when the simulation platform issues a state save request, it instructs the target simulation model whether the current save is a baseline save or an incremental save.

[0056] If the target simulation model has not saved its state data before the breakpoint time corresponding to the breakpoint identifier, a baseline save is performed. Specifically, the target simulation model outputs its complete state data as a baseline file to the model state storage area. Baseline saves are typically performed when a breakpoint is first set.

[0057] If the target simulation model has saved state data before the breakpoint time corresponding to the breakpoint identifier, incremental saving is performed. Specifically, the target simulation model obtains the binary difference data between the current state data and the most recently saved state data, and outputs this binary difference data as an incremental file to the model state storage area. The breakpoint index record contains the dependency order information between the incremental file and the baseline file.

[0058] The incremental saving method works as follows: the target simulation model divides the state data into fixed-length data blocks, compares each data block byte-by-byte with the baseline version or the previously saved version, records the positions of changed bytes and their changed values, forming a binary difference bitmap, which is then stored as the incremental file. For long-cycle simulation scenarios with frequent breakpoints, incremental saving can significantly reduce storage space overhead.

[0059] After saving, the target simulation model returns a save confirmation message to the simulation platform. The simulation platform persists the event data snapshot as an event queue snapshot file and associates this event queue snapshot file with the status data through breakpoint identifiers, forming a breakpoint index record. The breakpoint index record contains breakpoint identifiers, event queue snapshot file paths, and status file path information, used to locate the data that needs to be restored when the breakpoint is restarted.

[0060] During the saving process, the simulation platform starts an asynchronous save timer and records simulation models that have sent status save requests but have not yet returned save confirmation messages in the pending confirmation list.

[0061] If the list of pending confirmations is empty before the asynchronous save timer expires, then it is confirmed that all target simulation models have been saved.

[0062] If the pending confirmation list is not empty after the asynchronous save timer expires, the simulation platform only resends the state save request to the simulation models in the pending confirmation list and records a save exception log, which includes the timeout model identifier and the number of resends. This timeout retransmission mechanism prevents the entire breakpoint save process from being blocked due to slow response from individual models or network failures.

[0063] If the list of items to be confirmed is still not empty after being reissued, the simulation platform will mark the breakpoint index record as partially completed and continue to execute the subsequent breakpoint saving process.

[0064] The timeout for the asynchronous save timer is set by the user through configuration parameters, with a default value of 5 seconds. The pending confirmation list uses a hash table data structure, with the simulation model identifier as the key and the time the status save request was sent as the value.

[0065] When the simulation platform detects that the list of pending acknowledgments is not empty after the asynchronous save timer expires, it executes the following timeout retransmission strategy: First retransmission: Immediately resend the status save request to the simulation models in the pending confirmation list, and set the timeout to 3 seconds; Second retransmission: If the pending confirmation list is still not empty after the first retransmission, the status save request will be resent after waiting for 5 seconds, and the timeout will be set to 3 seconds. Third retransmission: If the pending confirmation list is still not empty after the second retransmission, the status save request will be resent for the third time after waiting for 10 seconds, and the timeout will be set to 3 seconds. If the list of pending confirmations is still not empty after the third retransmission, the simulation platform will mark the breakpoint index record as partially completed and record and save the exception log. The exception log includes the timeout model identifier, the number of retransmissions (recorded as 3), and the timeout timestamp.

[0066] When a breakpoint index record is marked as partially complete, the simulation platform continues to execute the subsequent breakpoint saving process. However, for simulation models that have timed out, it does not expect them to return a save confirmation message. The partially complete status is used to notify the user that the status data of the breakpoint is incomplete when the breakpoint is restarted.

[0067] A partially completed state indicates that the state data at the breakpoint was not fully saved, and these models will be marked as cold start models during subsequent recovery.

[0068] VI. Restarting from Breakpoint and Restoring State Users send a breakpoint restart command to the simulation platform through the user interface. This command contains the target breakpoint identifier. Based on the breakpoint identifier, the simulation platform loads the corresponding breakpoint context information from the breakpoint storage area and determines the set of simulation models that need to be restored based on the breakpoint index records.

[0069] Before issuing a state recovery request to the simulation model, the simulation platform performs a version verification process: loads the breakpoint context information from the breakpoint storage area, extracts the model version number from it, queries the target simulation model for the current model version number, and compares the queried current model version number with the model version number in the breakpoint context information.

[0070] If the comparison results are consistent, state recovery is allowed, and a state recovery request is sent to the target simulation model.

[0071] If the comparison results are inconsistent, the state recovery will be rejected, and a model version mismatch alarm will be output. This version verification mechanism prevents simulation errors caused by incompatibility between old state data and current model logic after model code updates.

[0072] For scenarios where some models lack available state data, the simulation platform sends a state existence query request to each simulation model via a standardized interface. This request carries a breakpoint identifier. Each simulation model returns a state existence query response via the standardized interface, which includes a boolean value indicating whether the current simulation model stores a state file corresponding to the breakpoint identifier.

[0073] The simulation platform marks simulation models that return a negative Boolean value as cold start models and those that return a positive Boolean value as recovery models. An initialization command, containing the current simulation time, is sent to the cold start model to start execution from its initial state and advance to the current simulation time. A state recovery request is sent to the recovery model to load the corresponding state data.

[0074] For incremental saving scenarios, the simulation platform sends a state recovery request to the target simulation model based on the dependency order information in the breakpoint index record, instructing it to load the base file and incremental file in the dependency order to reconstruct the complete state data.

[0075] After the cold start model completes its initialization and the recovery model completes its state data loading, the simulation platform sends a logical time synchronization signal to both models. This ensures that the cold start and recovery models are aligned at the current simulation time and proceed with the simulation together. This logical time synchronization mechanism guarantees that although the cold start and recovery models use different initialization methods during the recovery phase, they are at the same logical time position when the simulation resumes.

[0076] In this implementation, the state existence query request is in JSON format and includes the following fields: request type, breakpoint identifier, and model identifier. The state existence query response returned by each simulation model through the standardized interface is in JSON format and includes the following fields: response type, breakpoint identifier, model identifier, whether the state file exists, state file path, and state file size.

[0077] The specific process by which the simulation platform sends initialization commands to the cold start model is as follows: (1) The initialization instruction includes the current simulation time from the breakpoint context information; (2) The cold start model executes its internal simulation logic starting from simulation time 0; (3) The cold start model advances from time 0 to the current simulation time in accelerated execution mode, skipping the waiting for external input events during the process; (4) The cold start model does not generate output events during execution to avoid interfering with other models during the initialization process; (5) When the cold start model reaches the current simulation time, return an initialization completion signal to the simulation platform.

[0078] At the same time, the simulation platform restores the state of the event scheduling queue based on the event queue snapshot file, that is, restores the complete information of all simulation events that have not yet been dispatched when the breakpoint is triggered, including the event identifier, target model identifier, event execution time and event input data of each event.

[0079] VII. Differentiating Breakpoint Recovery Strategies The simulation platform executes different recovery strategies based on the breakpoint scope information.

[0080] If the breakpoint scope information is globally filtered, all simulation models are paused when the breakpoint is triggered. Upon resumption, all models resume synchronously from the breakpoint moment, with no time deviation between models. Therefore, the simulation platform synchronously resumes event distribution to all simulation models from the current simulation time.

[0081] If the breakpoint scope information is local filtered, only the target simulation model is paused when the breakpoint is triggered. Other models continue running and advance their logic clocks after the breakpoint is triggered. Therefore, upon resumption, the logic time of the target simulation model lags behind that of the other models. The simulation platform obtains the time offset between the current simulation time and the breakpoint time, and adds this offset to the execution time of each simulation event temporarily stored in the event buffer, aligning the execution time of each event with the current simulation time. Then, it sends time synchronization information containing the current simulation time to the target simulation model, resumes event distribution to the target simulation model, and re-injects the simulation events with aligned timestamps into the event scheduling queue. Other simulation models continue to execute events received during their continuous operation after the breakpoint is triggered.

[0082] The time offset equals the current simulation time of the simulation platform minus the breakpoint time in the breakpoint context information. After the execution time of each simulation event temporarily stored in the event buffer is increased by the time offset, each event is re-injected into the event scheduling queue according to the new timestamp order after recovery, and is then distributed and executed sequentially by the event dispatcher.

[0083] If the breakpoint scope information is local filtering, when the simulation platform restores the event distribution to the target simulation model, it sends time synchronization information to the target simulation model. The time synchronization information includes the current simulation time, so that the target simulation model knows the time target it needs to catch up with after restoration, and can correctly process the time-related internal logic when receiving subsequent events.

[0084] Through the aforementioned time offset correction mechanism, the target simulation model is restored to the current simulation time and aligned with other models, ensuring that the models maintain time consistency during the simulation process after restoration.

[0085] 8. Data Dependency Validation After restoring the state of the event scheduling queue, the simulation platform retrieves the consumption relationships between the undistributed simulation events in the event scheduling queue from the breakpoint context information. This involves understanding the consumption relationship between event input data and upstream event output data, and constructing a data dependency graph based on these relationships. In this graph, each node represents an undistributed simulation event, and each directed edge represents the consumption relationship between a downstream event and upstream event output data. Each directed edge is associated with and stores the state data fingerprint of the target simulation model corresponding to the upstream event at the breakpoint.

[0086] The simulation platform traverses each directed edge in the data dependency graph, obtains the real-time state data fingerprint of the target simulation model corresponding to each upstream event at the current moment, and compares the real-time state data fingerprint with the breakpoint state data fingerprint stored in association with the directed edge.

[0087] If all directed edges match, it indicates that the current state of each model is consistent with the breakpoint time, the data dependency relationship has not been broken, and the simulation platform maintains the original order of the simulation events in the event scheduling queue.

[0088] If a directed edge with an inconsistency exists, it indicates that the state of an upstream model has changed after a breakpoint, causing the data that downstream events depend on to be inconsistent with the data at the breakpoint. The simulation platform locates the downstream simulation event pointed to by the directed edge, traces upstream along the data dependency graph, identifies the upstream simulation event that caused the data dependency, moves the upstream simulation event and all its downstream simulation events to the head of the event scheduling queue and adds a forced execution flag, and executes them in the order they have been moved. Simultaneously, the simulation platform outputs a conflict diagnosis report, which includes the identification information of the directed edge with the inconsistency and a list of the identifications of the affected simulation events.

[0089] Through the above verification mechanism, the execution order of events after breakpoint recovery conforms to causal logic, avoiding data inconsistency caused by changes in model state.

[0090] IX. Consistency Verification After Recovery After completing the state recovery of all simulation models and distributing the recovery events to all simulation models, the simulation platform starts a consistency check timer. Before the consistency check timer expires, it intercepts the output events sent by the target simulation model to other simulation models, extracts the current state data carried in the output event, performs a hash operation on the current state data to generate a current state data fingerprint, and compares the current state data fingerprint with the state data fingerprint at the breakpoint time stored in the breakpoint context information.

[0091] If the comparison is consistent, the simulation platform will allow the output event to be passed to other simulation models.

[0092] If the comparison is inconsistent, it indicates that the target simulation model deviated from the behavior trajectory at the breakpoint during the restored operation. At this time, the simulation platform suspends event distribution for all simulation models, outputs a consistency alarm, which includes the fingerprint information of the inconsistency and the corresponding simulation model identifier, and provides the user with two recovery options: rollback to the breakpoint or continue forward.

[0093] The above-mentioned post-recovery verification mechanism sets up an observation window after the breakpoint is recovered to detect whether the behavior of the model after recovery is consistent with that before the breakpoint, so as to prevent simulation errors caused by incomplete state recovery from going undetected for a long time after recovery.

[0094] Based on the same inventive concept, this invention also provides a breakpoint restart device for a simulation system with a platform and model separation architecture, as described in the following embodiments. Since the principle of the breakpoint restart device for a simulation system with a platform and model separation architecture is similar to that of the breakpoint restart method for a simulation system with a platform and model separation architecture, the implementation of the breakpoint restart device for a simulation system with a platform and model separation architecture can refer to the implementation of the breakpoint restart method for a simulation system with a platform and model separation architecture; repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0095] Figure 3 This is a structural block diagram of a breakpoint restart device for a simulation system under a platform and model separation architecture, as described in this embodiment of the invention. Figure 3 As shown, it includes: simulation platform providing module 301, distribution module 302, breakpoint context generation module 303, state saving management module 304, breakpoint index record generation module 305, and breakpoint restart management module 306. The structure is described below.

[0096] The simulation platform provides module 301, which provides a simulation platform and multiple simulation models. The simulation platform and the simulation models interact through a standardized interface. The simulation platform manages the event scheduling queue, logical clock, and event distribution. The simulation models independently encapsulate state data and simulation logic. The distribution module 302 is used to obtain breakpoint configuration parameters, which include breakpoint identifiers and breakpoint triggering conditions. It constructs an event scheduling queue on the simulation platform, distributes simulation events to each simulation model according to the order of the event scheduling queue, and monitors whether the breakpoint triggering conditions are met during the distribution process. The breakpoint context generation module 303, when the breakpoint triggering condition is met, pauses the distribution of subsequent simulation events to the simulation model, determines the target simulation model and generates breakpoint context information, and stores it in the breakpoint storage area with the breakpoint identifier as the key. The breakpoint context information includes the current simulation time, a snapshot of the event data of the remaining simulation events that have not yet been distributed in the event scheduling queue, and the state data fingerprint of the target simulation model at the breakpoint time. The state saving management module 304 is used to send a state saving request to the target simulation model according to the breakpoint context information when a breakpoint saving instruction is received, so that the target simulation model can output its own state data to a model state storage area independent of the simulation platform according to the state saving request. The breakpoint index record generation module 305 is used to persist the event data snapshot as an event queue snapshot file, and associate the event queue snapshot file with the status data through the breakpoint identifier to form a breakpoint index record; The breakpoint restart management module 306 is used to, when receiving a breakpoint restart instruction, load the corresponding breakpoint context information and breakpoint index record according to the breakpoint identifier in the breakpoint restart instruction, restore the state of the event scheduling queue according to the event queue snapshot file, send a state recovery request to the corresponding simulation model according to the breakpoint index record to trigger each simulation model to load the state data, and continue to drive the simulation to run and perform consistency verification after the recovery is completed.

[0097] In one embodiment, the breakpoint context generation module includes: A breakpoint scope acquisition unit is used to acquire breakpoint scope information from the breakpoint configuration parameters, wherein the breakpoint scope information is used to instruct the event dispatcher of the simulation platform to perform global filtering or local filtering when the breakpoint is triggered. A global filtering execution unit is used to intercept all simulation events distributed to the target simulation model after the breakpoint is triggered when the breakpoint scope information is global filtering. The target simulation model is all simulation models. The target model determination unit is used to, when the breakpoint scope information indicates local filtering, obtain the target simulation model identifier from the breakpoint configuration parameters and determine the simulation model corresponding to the target simulation model as the target simulation model; A local filtering execution unit is used to enable the event dispatcher to only intercept simulation events destined for the simulation model corresponding to the target simulation model identifier after the breakpoint is triggered, and to continuously output simulation events destined for other simulation models. The logic clock of the simulation platform continues to advance after the breakpoint is triggered. An event cache storage unit is used to store the simulation events intercepted by the event dispatcher into the event cache area and record the cache event count; A buffer overflow protection unit is used to, when the count of the cached events reaches a preset threshold, cause the simulation platform to suspend the distribution of subsequent simulation events to the adjacent downstream models of the target simulation model and output a buffer overflow alarm. The cached event re-injection unit is used to, when a breakpoint restart instruction is received, re-inject the simulation events temporarily stored in the event cache into the event scheduling queue according to the original timestamp order of the simulation events by the event dispatcher.

[0098] In one embodiment, the breakpoint context generation module further includes: The state fingerprint generation unit is used to obtain the real-time state data of the target simulation model through a standardized interface, perform a hash operation on the real-time state data, and generate a state data fingerprint. The version number associated storage unit is used to obtain the current model version number of the target simulation model and associate the state data fingerprint with the model version number and store it in the breakpoint context information. The version number comparison unit is used to load the breakpoint context information from the breakpoint storage area, extract the model version number from the breakpoint context information, query the current model version number from the target simulation model, and compare the queried current model version number with the model version number in the breakpoint context information in response to the breakpoint restart command and before issuing the state recovery request to the target simulation model. The consistent recovery execution unit is used to allow the execution state to be restored if the comparison results are consistent, and to send the state restoration request to the target simulation model; The inconsistency rejection unit is used to refuse execution if the comparison results are inconsistent, and output a model version mismatch alarm.

[0099] In one embodiment, the state preservation management module includes: An asynchronous save initiation unit is used to send a state save request to the target simulation model, start an asynchronous save timer, and record simulation models that have sent state save requests but have not yet returned save confirmation messages in a list to be confirmed. The save confirmation unit is used to confirm that all target simulation models have completed state saving if the list to be confirmed is empty before the asynchronous save timer expires. The timeout retransmission unit is used to resend the status save request only to the simulation models in the pending confirmation list if the pending confirmation list is not empty after the asynchronous save timer expires, and to record the save exception log, which includes the timeout model identifier and the number of retransmissions. The partially completed marking unit is used so that if the list to be confirmed is still not empty after being reissued, the simulation platform marks the breakpoint index record as partially completed and continues to execute the subsequent breakpoint saving process.

[0100] In one embodiment, the state preservation management module further includes: The save type indicator unit is used to indicate to the target simulation model whether the current save is a baseline save or an incremental save when the state save request is issued; The benchmark saving execution unit is used to cause the target simulation model to perform the benchmark saving when the target simulation model has not saved its state data before the breakpoint time corresponding to the breakpoint identifier, and output its own state data as a benchmark file to the model state storage area. The incremental save execution unit is used to cause the target simulation model to perform the incremental save when the target simulation model has saved state data before the breakpoint time corresponding to the breakpoint identifier, to obtain the binary difference data between the current state data and the latest saved state data, and to output the binary difference data as an incremental file to the model state storage area. The breakpoint index record contains the dependency order information between the incremental file and the base file. The incremental reconstruction unit is used to, in response to a breakpoint restart instruction loading the state data, send a state recovery request to the target simulation model according to the dependency order information in the breakpoint index record, so that the target simulation model loads the base file and the incremental file sequentially according to the dependency order to reconstruct the state data.

[0101] In one embodiment, the breakpoint restart management module includes: The consumption relationship acquisition unit is used to acquire the consumption relationship between the event input data and the upstream event output data of each simulation event that has not yet been distributed in the event scheduling queue in the breakpoint context information; A dependency graph construction unit is used to construct a data dependency graph based on the consumption relationship, wherein each directed edge in the data dependency graph is associated with and stores the state data fingerprint of the target simulation model corresponding to the upstream event at the breakpoint time. The state fingerprint comparison unit is used to, after restoring the state of the event scheduling queue according to the event queue snapshot file, traverse each directed edge in the data dependency graph, obtain the real-time state data fingerprint of the target simulation model corresponding to each upstream event at the current time, and compare the real-time state data fingerprint with the breakpoint state data fingerprint stored in association with the directed edge. The consistent execution unit is used to ensure that if all directed edges are consistent, the simulation events in the event scheduling queue are executed in the original order. The conflict handling unit is used to locate the downstream simulation event pointed to by the directed edge if there is an inconsistency in the comparison, trace upstream along the data dependency graph, identify the upstream simulation event that caused the data dependency, move the upstream simulation event and all its downstream simulation events to the head of the event scheduling queue and add a forced execution mark, execute them in the order after the move, and output a conflict diagnosis report. The conflict diagnosis report includes the identification information of the inconsistent directed edge and the identification list of the affected simulation events.

[0102] In one embodiment, the breakpoint restart management module further includes: The state existence query unit is used to send a state existence query request to each simulation model through a standardized interface before the simulation platform sends a state recovery request to the corresponding simulation model. The state existence query request carries the breakpoint identifier. A state existence response receiving unit is used by the simulation platform to receive state existence query responses returned by each simulation model through the standardized interface. The state existence query response includes a Boolean value indicating whether the current simulation model stores a state file corresponding to the breakpoint identifier. The model classification and labeling unit is used by the simulation platform to label simulation models that return a negative Boolean value as cold start models and simulation models that return a positive Boolean value as recovery models. A cold start initialization unit is used by the simulation platform to issue an initialization instruction to the cold start model. The initialization instruction includes the current simulation time in the breakpoint context information, so that the cold start model starts execution from the initial state and advances to the current simulation time. A recovery model loading unit is used by the simulation platform to send the state recovery request to the recovery model so that the recovery model loads the state data. The logical time synchronization unit is used by the simulation platform to send a logical time synchronization signal to the cold start model and the recovery model after the cold start model has completed initialization and the recovery model has completed state data loading, so that the cold start model and the recovery model are aligned at the current simulation time and jointly promote the simulation operation.

[0103] In one embodiment, the breakpoint restart management module further includes: A global recovery execution unit is used to, if the breakpoint scope information is globally filtered, then the simulation platform will synchronously resume event distribution to all simulation models starting from the current simulation time. The time offset acquisition unit is used to acquire the time offset between the current simulation time of the simulation platform and the breakpoint time in the breakpoint context information if the breakpoint scope information is local filtering. The event timestamp alignment unit is used to add the time offset to the event execution time of each simulation event temporarily stored in the event buffer, so that the event execution time of each simulation event is aligned with the current simulation time. The time synchronization and local recovery unit is used to send time synchronization information to the target simulation model, the time synchronization information including the current simulation time, and to restore event distribution to the target simulation model. Events received by other simulation models during continuous operation after the breakpoint is triggered will continue to be executed. An event re-injection unit is used to re-inject the simulation event with aligned timestamps into the event scheduling queue.

[0104] In one embodiment, the breakpoint restart management module further includes: The consistency check initiation unit is used to start the consistency check timer after the state recovery of all simulation models is completed and the recovery event distribution of all simulation models is completed. The output event interception and fingerprint comparison unit is used to intercept the output events sent by the target simulation model to other simulation models before the consistency verification timer expires, extract the current state data carried in the output events, perform a hash operation on the current state data to generate a current state data fingerprint, and compare the current state data fingerprint with the breakpoint time state data fingerprint stored in the breakpoint context information. A consistent release unit is used to release the output event if the comparison is consistent. The inconsistency handling unit is used to pause the event distribution of all simulation models if there is an inconsistency, output a consistency alarm, and provide the user with two recovery options: rollback to the breakpoint or continue forward. The consistency alarm includes fingerprint information of the inconsistency and the corresponding simulation model identifier.

[0105] The embodiments of the present invention achieve the following technical effects: This invention addresses the platform-model separation characteristic of simulation architectures by implementing decoupled interaction between the simulation platform and various simulation models through standardized interfaces. The simulation platform handles breakpoint configuration, event distribution, state storage, and recovery scheduling, while each simulation model responds to state saving and recovery requests via standardized interfaces. This mechanism is independent of the internal implementation details of any specific simulation model and is applicable to various simulation models from different fields and developers.

[0106] By introducing breakpoint scope information, the event distribution behavior after a breakpoint is triggered can be configured as global or local filtering according to user needs. In global filtering mode, event distribution for all simulation models is paused, suitable for system-level debugging and global status checks. In local filtering mode, event distribution for only the target simulation model is paused, while other simulation models continue running and the simulation platform's logic clock continues to advance, avoiding the stagnation of irrelevant models and the waste of simulation resources caused by global pauses in traditional breakpoint methods.

[0107] This invention separates the platform state from the model state for storage, allowing the event scheduling queue state of the simulation platform and the state data of each simulation model to be saved and loaded independently. When the simulation model is updated or replaced, the old platform state data can still be reused; only the model-side state data needs to be saved again, avoiding the problem of the entire checkpoint file becoming invalid due to model changes, as is common in traditional overall snapshot methods. Simultaneously, the incremental saving mechanism ensures that the first save outputs complete state data as a baseline file, while subsequent saves only output binary difference data, reducing storage space overhead in scenarios with frequent breakpoints.

[0108] By recording the consumption relationships between events using a data dependency graph and comparing state fingerprints after recovery, it can automatically detect changes in the state of upstream models caused by the continued operation of other models after a breakpoint is triggered. When state inconsistency is detected, the affected events are rescheduled upstream to ensure that the execution order of the recovered events conforms to causal logic, thus avoiding data inconsistency issues caused by changes in model state.

[0109] In this embodiment of the invention, after recovery is complete, a consistency verification timer is started. Within a preset verification window, output events sent by the target simulation model to other models are intercepted and compared with the state fingerprint at the breakpoint. This allows for timely detection of whether the model behavior deviates from expectations after recovery. When a deviation is detected, the system provides two recovery options: rollback to the breakpoint or continue forward, enabling users to respond flexibly according to their actual needs.

[0110] This invention employs a state existence query mechanism to distinguish between recovery models with existing state files and cold-start models without state files before recovery. State loading and initialization are performed separately for each model, and a logical time synchronization signal aligns the two types of models at the current simulation time. This mechanism allows the simulation task to recover and continue normally even when some models lack usable state data, avoiding the problem of the entire simulation failing due to the missing state of individual models.

[0111] This invention, through an asynchronous timer and a pending confirmation list mechanism, can identify and handle simulation models with timeouts during state saving. Timeout retransmission ensures the integrity of the saved state data, and after multiple failed retransmissions, the breakpoint index is marked as partially completed, allowing subsequent recovery processes to distinguish between fully saved and partially saved breakpoints. Furthermore, this invention supports dynamic configuration of breakpoint parameters during simulation execution, taking effect without stopping the simulation, thus improving the flexibility of breakpoint operations.

[0112] Obviously, those skilled in the art should understand that the modules or steps of the above-described embodiments of the present invention can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of the present invention are not limited to any particular hardware and software combination.

[0113] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations can be made to the embodiments of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for restarting a simulation system with a platform and model separation architecture, characterized in that, include: A simulation platform and multiple simulation models are provided. The simulation platform and the simulation models interact through a standardized interface. The simulation platform manages the event scheduling queue, logical clock, and event distribution. The simulation models independently encapsulate state data and simulation logic. Obtain breakpoint configuration parameters, construct an event scheduling queue on the simulation platform, distribute simulation events to each simulation model according to the order of the event scheduling queue, and monitor whether the breakpoint triggering conditions are met during the distribution process. The breakpoint configuration parameters include breakpoint identifier and breakpoint triggering conditions. When the breakpoint triggering condition is met, the distribution of subsequent simulation events to the simulation model is paused, the target simulation model is determined and breakpoint context information is generated, and the breakpoint identifier is stored in the breakpoint storage area. The breakpoint context information includes the current simulation time, a snapshot of the event data of the remaining simulation events that have not yet been distributed in the event scheduling queue, and the state data fingerprint of the target simulation model at the breakpoint time. When a breakpoint save command is received, a state save request is sent to the target simulation model according to the breakpoint context information. The target simulation model outputs its own state data to a model state storage area independent of the simulation platform according to the state save request. The event data snapshot is persisted as an event queue snapshot file, and the event queue snapshot file and the status data are associated and stored through the breakpoint identifier to form a breakpoint index record; When a breakpoint restart command is received, the corresponding breakpoint context information and breakpoint index record are loaded according to the breakpoint identifier in the breakpoint restart command. The state of the event scheduling queue is restored according to the event queue snapshot file. A state recovery request is sent to the corresponding simulation model according to the breakpoint index record to trigger each simulation model to load the state data. After the recovery is completed, the simulation continues to run and a consistency check is performed.

2. The breakpoint restart method as described in claim 1, characterized in that, Suspend the distribution of subsequent simulation events to the simulation model, including: The breakpoint scope information is obtained from the breakpoint configuration parameters, wherein the breakpoint scope information is used to instruct the event dispatcher of the simulation platform to perform global filtering or local filtering when the breakpoint is triggered. When the breakpoint scope information is global filtering, the event dispatcher intercepts all simulation events dispatched to the target simulation model after the breakpoint is triggered, and the target simulation model is all simulation models; When the breakpoint scope information indicates local filtering, the simulation platform obtains the target simulation model identifier from the breakpoint configuration parameters and determines the simulation model corresponding to the target simulation model as the target simulation model. The event dispatcher intercepts only simulation events destined for the target simulation model after the breakpoint is triggered, and continuously outputs simulation events destined for other simulation models. The logic clock of the simulation platform continues to advance after the breakpoint is triggered. The simulated events intercepted by the event dispatcher are stored in the event cache area, and the cache event count is recorded; When the cached event count reaches a preset threshold, the simulation platform suspends the distribution of subsequent simulation events to the adjacent downstream models of the target simulation model and outputs a cache overflow alarm. Upon receiving a breakpoint restart command, the event dispatcher re-injects the simulation events temporarily stored in the event buffer into the event scheduling queue according to the original timestamp order of the simulation events.

3. The breakpoint restart method as described in claim 1, characterized in that, Generate breakpoint context information, including: The simulation platform obtains the real-time state data of the target simulation model through a standardized interface, performs a hash operation on the real-time state data, and generates a state data fingerprint. Obtain the current model version number of the target simulation model, and associate the state data fingerprint with the model version number and store it in the breakpoint context information; In response to the breakpoint restart command and before sending a state recovery request to the target simulation model, the simulation platform loads the breakpoint context information from the breakpoint storage area, extracts the model version number from the breakpoint context information, queries the target simulation model for the current model version number, and compares the queried current model version number with the model version number in the breakpoint context information. If the comparison results are consistent, state recovery is allowed, and the state recovery request is sent to the target simulation model; If the comparison results are inconsistent, the state recovery will be refused and a model version mismatch alarm will be output.

4. The breakpoint restart method as described in claim 1, characterized in that, Based on the breakpoint context information, a state save request is sent to the target simulation model, including: After the simulation platform sends a state save request to the target simulation model, it starts an asynchronous save timer and records the simulation models that have sent a state save request but have not yet returned a save confirmation message in the pending confirmation list. If the list of pending confirmations is empty before the asynchronous save timer expires, then it is confirmed that all target simulation models have completed state saving. If the pending confirmation list is not empty after the asynchronous save timer expires, the simulation platform will only resend the status save request to the simulation models in the pending confirmation list and record a save exception log, which includes the timeout model identifier and the number of resends. If the list of items to be confirmed is still not empty after being reissued, the simulation platform will mark the breakpoint index record as partially completed and continue to execute the subsequent breakpoint saving process.

5. The breakpoint restart method as described in claim 1, characterized in that, The target simulation model outputs its own state data to a model state storage area independent of the simulation platform according to the state saving request, including: When the simulation platform issues the state save request, it instructs the target simulation model whether the current save is a baseline save or an incremental save. When the target simulation model has not saved state data before the breakpoint time corresponding to the breakpoint identifier, the target simulation model performs the baseline saving and outputs its own state data as a baseline file to the model state storage area. When the target simulation model has saved state data before the breakpoint time corresponding to the breakpoint identifier, the target simulation model performs incremental saving, obtains binary difference data between the current state data and the latest saved state data, and outputs the binary difference data as an incremental file to the model state storage area. The breakpoint index record contains the dependency order information between the incremental file and the baseline file. When the simulation platform responds to the breakpoint restart command and loads the state data, it sends the state recovery request to the target simulation model according to the dependency order information in the breakpoint index record, so that the target simulation model loads the base file and the incremental file in the dependency order to reconstruct the state data.

6. The breakpoint restart method as described in claim 1, characterized in that, Load the corresponding breakpoint context information, including: Obtain the consumption relationship between the event input data and the upstream event output data among the simulation events that have not yet been distributed in the event scheduling queue from the breakpoint context information; The consumption relationship forms a data dependency graph, wherein each directed edge in the data dependency graph stores the state data fingerprint of the target simulation model corresponding to the upstream event at the breakpoint time. After the simulation platform restores the state of the event scheduling queue according to the event queue snapshot file, it traverses each directed edge in the data dependency graph to obtain the real-time state data fingerprint of the target simulation model corresponding to each upstream event at the current time, and compares the real-time state data fingerprint with the breakpoint state data fingerprint stored in association with the directed edge. If all directed edges match, then the simulation events in the event scheduling queue will be sent out and executed in the original order. If there are inconsistent directed edges, the downstream simulation event pointed to by the directed edge is located, and the upstream simulation event that caused the data dependency is identified by tracing upstream along the data dependency graph. The upstream simulation event and all its downstream simulation events are moved to the head of the event scheduling queue and a forced execution mark is added. They are then executed in the order after the move, and a conflict diagnosis report is output. The conflict diagnosis report contains the identification information of the inconsistent directed edges and the identification list of the affected simulation events.

7. The breakpoint restart method as described in claim 1, characterized in that, Based on the breakpoint index record, a state recovery request is sent to the corresponding simulation model to trigger each simulation model to load the state data, including: Before the simulation platform sends a state recovery request to the corresponding simulation model, it sends a state existence query request to each simulation model through a standardized interface. The state existence query request carries the breakpoint identifier. The simulation platform receives state existence query responses returned by each simulation model through the standardized interface. The state existence query response includes a Boolean value indicating whether the current simulation model stores a state file corresponding to the breakpoint identifier. The simulation platform marks simulation models that return a negative Boolean value as cold start models and simulation models that return a positive Boolean value as recovery models. The simulation platform sends an initialization command to the cold start model. The initialization command includes the current simulation time in the breakpoint context information, so that the cold start model starts execution from the initial state and advances to the current simulation time. The simulation platform sends the state recovery request to the recovery model so that the recovery model loads the state data. After the cold start model completes its initialization and the recovery model completes its state data loading, the simulation platform sends a logical time synchronization signal to the cold start model and the recovery model, so that the cold start model and the recovery model are aligned at the current simulation time and jointly advance the simulation.

8. The breakpoint restart method as described in any one of claims 1 to 7, characterized in that, After recovery, continue driving the simulation, including: If the breakpoint scope information is global filtering, then the simulation platform will synchronously resume event distribution to all simulation models starting from the current simulation time; If the breakpoint scope information is local filtering, then the simulation platform obtains the time offset between the current simulation time of the simulation platform and the breakpoint time in the breakpoint context information; The execution time of each simulation event temporarily stored in the event buffer is increased by the time offset to align the execution time of each simulation event with the current simulation time. Time synchronization information, including the current simulation time, is sent to the target simulation model. Event distribution is then restored to the target simulation model, and events received by other simulation models during continuous operation after the breakpoint is triggered continue to be executed. The simulation event with the aligned timestamp is re-injected into the event scheduling queue.

9. The breakpoint restart method as described in any one of claims 1 to 7, characterized in that, Perform consistency checks, including: After the simulation platform completes the state recovery of all simulation models and distributes the recovery event to all simulation models, it starts a consistency check timer. Before the consistency check timer expires, the simulation platform intercepts the output events sent by the target simulation model to other simulation models, extracts the current state data carried in the output events, performs a hash operation on the current state data to generate a current state data fingerprint, and compares the current state data fingerprint with the breakpoint time state data fingerprint stored in the breakpoint context information. If the comparison matches, the simulation platform allows the output event to proceed. If the comparison is inconsistent, the simulation platform will pause the event distribution of all simulation models, output a consistency alarm, and provide the user with two recovery options: rollback to the breakpoint or continue forward. The consistency alarm includes fingerprint information of the inconsistency and the corresponding simulation model identifier.

10. A breakpoint restart device for a simulation system with a platform and model separation architecture, characterized in that, include: The simulation platform provides a module for providing a simulation platform and multiple simulation models. The simulation platform and the simulation models interact through a standardized interface. The simulation platform manages the event scheduling queue, logical clock, and event distribution. The simulation models independently encapsulate state data and simulation logic. The distribution module is used to obtain breakpoint configuration parameters, which include breakpoint identifiers and breakpoint triggering conditions. It constructs an event scheduling queue on the simulation platform, distributes simulation events to each simulation model according to the order of the event scheduling queue, and monitors whether the breakpoint triggering conditions are met during the distribution process. The breakpoint context generation module is used to pause the distribution of subsequent simulation events to the simulation model when the breakpoint triggering condition is met, determine the target simulation model and generate breakpoint context information, and store it in the breakpoint storage area with the breakpoint identifier as the key. The breakpoint context information includes the current simulation time, a snapshot of the event data of the remaining simulation events that have not yet been distributed in the event scheduling queue, and the state data fingerprint of the target simulation model at the breakpoint time. The state saving management module is used to send a state saving request to the target simulation model according to the breakpoint context information when a breakpoint saving instruction is received, so that the target simulation model can output its own state data to a model state storage area independent of the simulation platform according to the state saving request. The breakpoint index record generation module is used to persist the event data snapshot as an event queue snapshot file, and associate the event queue snapshot file with the status data through the breakpoint identifier to form a breakpoint index record; The breakpoint restart management module is used to, when a breakpoint restart instruction is received, load the corresponding breakpoint context information and breakpoint index record according to the breakpoint identifier in the breakpoint restart instruction, restore the state of the event scheduling queue according to the event queue snapshot file, send a state recovery request to the corresponding simulation model according to the breakpoint index record to trigger each simulation model to load the state data, and continue to drive the simulation to run and perform consistency verification after the recovery is completed.

Images