A data declaration-based simulation process breakpoint reading and writing method

Abstract

The application discloses a simulation process breakpoint read-write method based on data declaration and belongs to the technical field of simulation software. The method divides data in a simulation process into fixed data and change data, describes the change data which needs to be persisted in a tree structure through data declaration, and includes variable types, variable names and organization types. After the simulation is manually interrupted, binary values of the change data are sequentially written into a storage medium according to a depth-first traversal algorithm based on the data declaration; after the simulation is restarted, the breakpoint data is sequentially read according to the same data declaration structure and is assigned to the reinitialized simulation object, so that the simulation is continued from the breakpoint time. The application does not need to change the program structure of the original simulation software, realizes the decoupling of the breakpoint read-write function and the simulation logic, has the advantages of non-invasiveness, small development workload, high read-write efficiency, data safety and zero runtime overhead, and is suitable for various complex simulation systems developed based on object-oriented languages.

Description

Technical Field

[0001] This application relates to the field of simulation software technology, and more specifically, to a method, system, and storage medium for reading and writing breakpoints in a simulation process based on data declaration. Background Technology

[0002] In the field of simulation technology, especially in applications involving the modeling and simulation of complex systems, a reasonable software architecture design is to adopt a "simulation engine + simulation model" model. The simulation engine is responsible for coordinating and scheduling time-related tasks and various simulation events, ensuring the orderly progress of the simulation logic; the simulation model is responsible for implementing specific business logic, solving the corresponding business equations when events are triggered, and updating the data state within the model. Under this architecture, the simulation process often involves the interaction of numerous model objects and lengthy computation times.

[0003] When simulations are lengthy or computationally complex, the process may encounter various interruptions. For example, a simulation might unexpectedly terminate due to hardware failure, operating system updates, or other external factors; operators might need to pause for rest or analysis of intermediate results; or computer equipment might need to be shut down to conserve energy. In these situations, if the simulation software lacks breakpoint saving and resumption capabilities, restarting the simulation typically requires resuming from the initial point. This not only renders a significant amount of previously completed computational work useless but also severely impacts the efficiency and flexibility of the simulation task. Especially for long-cycle simulations that take days or even weeks to complete, the lack of breakpoint resumption capabilities is virtually unacceptable.

[0004] Currently, the technical solutions for saving and restoring breakpoints in the simulation process can be mainly divided into two categories.

[0005] The first type is the "embedded" approach, where a dedicated data structure or data management framework for storing and retrieving simulation data is pre-planned and designed at the initial stage of simulation software design. During simulation, a dedicated data manager manages all model data that needs to be persisted. When a breakpoint needs to be saved, the data manager serializes the data according to the predetermined structure and writes it to a file; during recovery, the data is deserialized and restored. The advantages of this approach are centralized data management, unified processes, and high integration with the simulation engine. However, its disadvantages are also quite obvious. First, this approach imposes strong constraints on the design of the simulation software. Once the data structure is determined, adding new models or expanding the data members of existing models often requires simultaneous modifications to the data manager and serialization logic, resulting in poor scalability and high maintenance costs. Second, because the data manager typically uses a "full save" approach, regardless of whether the data changes before or after the breakpoint, it is written along with the data, resulting in a huge amount of data to be stored and low read / write efficiency. Finally, this embedded design tightly couples the breakpoint functionality with the core simulation logic, violating the single responsibility principle and open / closed principle in software engineering.

[0006] The second type is the "plug-in" approach, which doesn't involve any unified architectural design for breakpoint functionality. Instead, it involves writing dedicated data saving and reading programs for each simulation model. When breakpoints need to be saved, these programs are called to write out the model's key data one by one; during recovery, they are read back one by one. The advantage of this approach is its extremely high degree of flexibility. The design of the simulation engine and simulation model can completely ignore breakpoint requirements, maintaining the clarity of their original business logic. Breakpoint read / write functionality is decoupled from the model implementation, ensuring no interference. However, the disadvantages of this approach are equally prominent: the workload is enormous and repetitive. For a complex simulation system containing hundreds or thousands of model classes, writing serialization code separately for each class will consume a significant amount of development time and is prone to data omissions or misalignments due to human error, leading to a nightmare of code maintenance.

[0007] In summary, both existing breakpoint read / write solutions have significant drawbacks. The former sacrifices software flexibility and scalability for process uniformity, while the latter is difficult to widely apply in real-world projects due to excessively high development and maintenance costs. Therefore, there is an urgent need for a new breakpoint read / write solution that combines the advantages of both, decoupling breakpoint read / write functionality from the core simulation logic, and eliminating the need to write lengthy and repetitive code for each model. Summary of the Invention

[0008] To overcome the aforementioned deficiencies in existing technologies, this application provides a data-declaration-based method for reading and writing breakpoints in simulation processes. This method can add complete breakpoint saving and recovery functions to simulation software in a declarative and non-intrusive manner without altering the original simulation engine and simulation model framework design, thereby effectively solving the problem of interrupted continuation of calculations during long-cycle simulations.

[0009] The core concept of this application lies in describing the storage location, data type, and organizational structure of data (mainly changing data) that needs to be persisted during simulation through a "data declaration" method independent of the simulation business logic. This data declaration is organized in a tree structure, consistent with the native object tree structure of the simulation model in memory. When saving at a breakpoint, the system does not write save code for each model individually; instead, it traverses the data declaration tree, using the metadata recorded in the declaration (such as variable type, name, offset in the object, or access path) to automatically extract the corresponding data values ​​from the simulation objects in memory and write them to the storage medium in depth-first order. When resuming from a breakpoint, the system again uses the same data declaration tree to read data from the storage medium sequentially and automatically assigns it back to the simulation objects in memory. The entire process achieves complete separation between the breakpoint read / write logic and the simulation business logic.

[0010] Specifically, this application provides a simulation process breakpoint read / write method based on data declaration, including: pre-configuring data declarations, wherein the data declarations describe the changing data that needs to be persisted in the simulation object tree in a tree structure; During simulation operation, the simulation process is paused in response to a simulation interruption command. Based on the tree structure declared by the data, a depth-first traversal algorithm is used to extract the values ​​of the corresponding changed data from the simulation object tree in memory, and write them sequentially into the storage medium to generate breakpoint data. After restarting the simulation process and performing simulation initialization, the breakpoint data is loaded, and the breakpoint data is read sequentially according to the structure of the data declaration, and assigned to the corresponding position in the re-initialized simulation object tree, so as to continue the simulation process from the breakpoint.

[0011] Optionally, the data declaration includes variable type, variable name, and organization type. The variable type is a built-in variable type of the programming language used by the simulation software, as well as a custom data type related to the simulation business. The variable name is a data identifier, and the organization type is a description representing the inclusion and reference relationships between data. The data declaration method is used to determine the changed data that needs to be recorded. The changed data that needs to be persisted in the simulation object tree may change in value after initialization.

[0012] Optionally, the response to the simulation interruption instruction includes: an instruction generated in response to a trigger operation of the user interface, an instruction generated by a timed saving program, or an instruction generated by a simulation program exception handling mechanism.

[0013] Optionally, the breakpoint data record takes the same form as the data declaration, and is stored in the storage medium using a tree-like organization. The data storage order is consistent with the data declaration. The data declaration describes the storage location of the changed data in the simulation data structure, and, like the changed data, is also organized in a tree structure.

[0014] Optionally, after restarting the simulation process, the breakpoint record data is read sequentially according to the data declaration structure, and the subsequent simulation process continues from the breakpoint time.

[0015] Optionally, the data declaration is organized in a tree structure, and the breakpoint data records are traversed using a depth-first algorithm and stored sequentially on a storage medium such as a disk in the form of data files.

[0016] Optionally, after restarting the simulation process, simulation initialization will be performed and some changed data will be assigned. Then, according to the data declaration structure, data will be read sequentially from the breakpoint data file and the simulation object data will be reconstructed in memory.

[0017] Based on the same inventive concept, this application also provides a simulation process breakpoint read / write system based on data declaration, the system comprising: The data declaration module is used to pre-configure data declarations; The breakpoint saving module is used to pause the simulation process in response to the simulation interruption command during the simulation run. Based on the tree structure of the data declaration, it uses a depth-first traversal algorithm to extract the values ​​of the corresponding changed data from the simulation object tree in memory and writes them sequentially to the storage medium to generate breakpoint data. The breakpoint reading module is used to load the breakpoint data after restarting the simulation process and performing simulation initialization, read the breakpoint data in sequence according to the structure of the data declaration, and assign the data to the corresponding position in the re-initialized simulation object tree so as to continue the simulation process from the breakpoint.

[0018] Based on the same inventive concept, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the aforementioned data declaration-based simulation process breakpoint read / write method.

[0019] Based on the same inventive concept, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the aforementioned data declaration-based simulation process breakpoint read / write method.

[0020] This application discloses the following technical effects: 1. Simplified development: By using data declaration, developers only need to declare "which data needs to be saved" without writing procedural code on "how to save and read", which greatly reduces the workload of implementing breakpoint functionality; 2. Read-write consistency: The same data declaration drives both the save and read processes simultaneously, fundamentally avoiding inconsistencies caused by manually writing save and read code; 3. Non-intrusive design: Data declarations are independent of the specific implementation of the simulation model. The source code of the simulation model does not need to be modified to support the breakpoint function, which achieves functional decoupling, conforms to the open / closed principle, and is conducive to the smooth upgrade of existing systems and the free expansion of models. 4. Wide applicability: It supports mainstream object-oriented programming languages ​​and can be easily implemented through mechanisms such as macros, templates, reflection, or annotations, making it highly portable and versatile; 5. High efficiency and security: It adopts binary sequential storage, does not save redundant identification information, has high read and write efficiency, and small storage space. At the same time, since the structure of the data file is entirely defined by the data declaration, the file content cannot be parsed without knowing the data declaration, thus providing a certain degree of data security protection; 6. Zero runtime overhead: During normal operation of the simulation software, the breakpoint read / write module does not consume any CPU or memory resources. Data saving or loading is only performed when the user explicitly triggers a breakpoint operation, which has no impact on the performance of the main simulation flow. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly described 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. Figure 1 This is a schematic diagram of the tree structure of the simulation model data provided in the embodiments of this application; Figure 2 This is a schematic diagram illustrating the data declaration of the root simulation object class provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating data declaration for a platform model class provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the data declaration of a motor vehicle model class provided in an embodiment of this application; Figure 5This is a flowchart illustrating the breakpoint saving and reading process provided in the embodiments of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0023] The following section uses ArkSIM, a distributed simulation software, as an example to illustrate the technical solution of this application. ArkSIM simulation software is developed using the C++ object-oriented programming language, and its core simulation model presents a typical tree-like data structure. For example... Figure 1 As shown, the root simulation object is the `WsfSimulation` class, which manages the simulation clock, environment configuration, and a series of simulation entities. Each simulation entity, such as the `WsfPlatform` class, represents a specific combat unit or physical object. The `WsfPlatform` class may contain multiple sub-models, such as the `WsfMover` class, which is responsible for calculating the platform's kinematic characteristics. This tree-like structure formed by object composition is a common data organization method in complex simulation systems.

[0024] In traditional development models, adding breakpoint read / write functionality to ArkSIM requires either designing a complete serialization mechanism for each class (WsfSimulation, WsfPlatform, WsfMover, etc.) (an embedded approach), or writing separate functions for saving and retrieving data for each class (an external approach). In systems like ArkSIM with a large number of model classes and complex relationships, the drawbacks of both approaches are dramatically amplified.

[0025] This embodiment uses the breakpoint read / write method based on data declaration proposed in this application. The specific implementation steps are as follows:

[0026] Step 1: Analyze and distinguish between fixed data and changing data First, classify the data members in the simulation model from a business perspective. Take the WsfPlatform class as an example: - Fixed data: `m_Height` (height), `m_Length` (length), `m_Width` (width), `m_EmptyMass` (empty weight). These data are loaded from the configuration file before the simulation begins and remain unchanged throughout the simulation, describing the platform's inherent geometric and physical properties. - Variable data: `m_FuelMass` (fuel mass), `m_PayloadMass` (load weight), `m_DamageFactor` (damage factor), `m_ConcealmentFactor` (concealment factor). These data will be dynamically updated over time and with events (such as resupply, attack, and environmental changes) during simulation. Similarly, for the WsfMover class: - Fixed data: `m_UpdateInterval` (motion solution update interval). This value is determined during model initialization and is usually not changed. - Changed data: `m_LastUpdateTime` (last update time). This value is updated after each motion calculation and is used to control the calculation frequency. It's important to note that this categorization only applies to breakpoint read / write functionality. The original design of the WsfPlatform and WsfMover classes did not include any breakpoint-related code, and their member variables did not distinguish between "fixed" and "variable" properties. The categorization information required for breakpoint functionality is defined entirely in separate data declarations.

[0027] Step 2: Constructing the data declaration This embodiment uses C++ macros to declare data. The advantage of this approach is that macros can be embedded in class definitions, naturally retrieving the class name, member variable names, and types. Furthermore, macro expansion generates auxiliary code for subsequent saving and retrieving. At the same time, this approach has minimal intrusion into the original class definition, requiring only a few lines of macro declarations without modifying any of the class's business logic. The specific declaration process is as follows: First, declare the root simulation object class WsfSimulation. For example... Figure 2As shown, the definition of the WsfSimulation class begins with the macro `DECLARE_SIM_OBJECT`, and uses the `DECLARE_VAR` macro to mark member variables that need to be saved. For example, the simulation time `m_SimTime` is a variable that needs to be saved. Simultaneously, this class holds an array of pointers to `WsfPlatform` objects, therefore, the `DECLARE_OBJECT_ARRAY` macro declares an array of objects, indicating that each `WsfPlatform` object in the array needs to be recursively processed when traversing the data declaration tree. Next, declare the WsfPlatform class. For example... Figure 3 As shown, in addition to declaring its own fixed and variable data, it is also necessary to declare its inclusion relationship with the sub-model WsfMover. Finally, declare the WsfMover class. For example... Figure 4 As shown, declare the changed data that needs to be saved. Through the macro definitions described above, the system can collect the metadata (type, name, offset in the object, container relationship, etc.) of all data members that need to be saved during compilation, and automatically construct a "data declaration tree" that completely corresponds to the tree structure of the simulation object. The nodes of this tree not only contain the original data, but also the "code" (accessors generated by macros) on how to access this data.

[0028] Step 3: Implement the breakpoint handling class Next, we will design a breakpoint handling class, `CheckpointManager`. This class is the core executor of this method; it does not depend on any specific simulation model, but instead performs general data read and write operations by manipulating the data declaration tree. The `CheckpointManager` class provides two core interface functions: - `bool saveCheckpoint(void* rootObject, const std::string& filePath)`: This function takes a pointer to the emulated root object and a target file path. It first retrieves the associated data declaration tree based on the type of the root object. Then, it creates a binary output stream. Next, it traverses the data declaration tree using a depth-first search algorithm. For each data declaration node encountered, it recursively calculates the actual memory address of the data, starting from the root object, using the access information stored in the node (such as member offsets), reads its current value, and then writes the raw binary representation of that value to the output stream. After the traversal is complete, the data in memory is flushed to the disk file. For object arrays and object pointer nodes, the function recursively calls itself to ensure the entire object tree is processed completely. - `bool loadCheckpoint(void* rootObject, const std::string& filePath)`: This function is the reverse of the save procedure. It takes a pointer to the emulation root object and the breakpoint file path. First, it retrieves the data declaration tree based on the root object type. Then, it creates a binary input stream. It then traverses the data declaration tree again in depth-first order. For each node, it reads a segment of binary data matching the data size from the input stream and, using the access information stored in the node, writes this data directly to the memory address calculated from the root object. This process overwrites the original values ​​in memory. For object arrays and object pointer nodes, it also processes them recursively to ensure the entire object tree is correctly restored. This class implementation utilizes C++ templates, pointer arithmetic, and type erasure techniques, enabling it to handle objects of any type without requiring specific code to be written for each model class. When the data declaration macros expand, they actually generate static metadata for `CheckpointManager` to call, achieving a "code is data" effect.

[0029] Step 4: Integration into simulation applications This step involves integrating the breakpoint functionality into the ArkSIM simulation software's interface and main workflow. Two buttons have been added to the existing simulation interface: "Save Breakpoint" and "Execute from Breakpoint". The click event handling logic for the "Save Breakpoint" button is as follows: 1. Obtain the current state of the simulation engine and call the engine's pause interface to ensure that the simulation is in a static state. 2. Create a `CheckpointManager` instance. 3. A file save dialog box will pop up, allowing the user to select the save path for the breakpoint file (e.g., `sim_breakpoint.dat`). 4. Obtain the pointer `pSimulation` to the root object of the current simulation world. 5. Call `checkpointMgr.saveCheckpoint(pSimulation, selectedFilePath)`. 6. If the save is successful, prompt the user; otherwise, report an error. 7. Resume the simulation engine running (or keep it paused, at the user's discretion). The click event handling logic for the "Execute from Breakpoint" button is as follows: 1. A file open dialog box pops up, allowing the user to select the previously saved breakpoint file. 2. Reset the entire simulation environment. This includes: reloading the simulation scenario file, performing a complete simulation initialization process to create a brand new simulation object tree, and assigning initial values ​​to both fixed and variable data. 3. Create a `CheckpointManager` instance. 4. Obtain the pointer `pSimulation` to the newly initialized root object of the simulation world. 5. Call `checkpointMgr.loadCheckpoint(pSimulation, selectedFilePath)`. 6. If loading is successful, the breakpoint data has been overwritten in the simulation object tree, and the simulation state has been precisely restored to the breakpoint time. Finally, start the simulation engine and continue running from the current time (i.e., the value after `m_SimTime` has been overwritten). 7. If loading fails, the initial state will be retained, and you can choose to restart the simulation.

[0030] Step 5: Verification and Results Through the above implementation, the ArkSIM simulation software successfully added complete breakpoint read / write functionality without modifying any existing model business logic code. In actual testing, for a simulation task running continuously for 8 hours, the "save breakpoint" operation was triggered at the 4th hour, generating a breakpoint file of several hundred KB. The simulation software was then closed and restarted. After loading the file using "execute from breakpoint," the simulation resumed from the state after the 4th hour, and the simulation results obtained at the end of the 8 hours were completely consistent with the results obtained from continuous execution for 8 hours without interruption. This verifies the correctness and effectiveness of the method. Furthermore, because breakpoint files are stored sequentially in binary format and do not contain metadata such as field names, their file size is much smaller than equivalent data stored in text formats (such as XML or JSON). Meanwhile, since `CheckpointManager` does not perform any operations in the main simulation loop, its impact on simulation efficiency is zero.

[0031] In summary, the simulation process breakpoint read / write method provided in this application introduces independent data declarations, which efficiently and flexibly endow simulation software with the ability to resume calculations from breakpoints in a declarative and non-intrusive manner. This effectively solves the problem of interrupted calculations during long-cycle simulations and has extremely high practical value and promising prospects for promotion.

[0032] The above description is merely a preferred embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for reading and writing breakpoints in a simulation process based on data declaration, characterized in that, include: Pre-configure data declarations, which describe the changing data that needs to be persisted in the simulation object tree in a tree structure; During simulation operation, the simulation process is paused in response to a simulation interruption command. Based on the tree structure declared by the data, a depth-first traversal algorithm is used to extract the values ​​of the corresponding changed data from the simulation object tree in memory, and write them sequentially into the storage medium to generate breakpoint data. After restarting the simulation process and performing simulation initialization, the breakpoint data is loaded, and the breakpoint data is read sequentially according to the structure of the data declaration, and assigned to the corresponding position in the re-initialized simulation object tree, so as to continue the simulation process from the breakpoint.

2. The simulation process breakpoint read / write method based on data declaration according to claim 1, characterized in that, The data declaration includes variable type, variable name, and organization type. The variable type is a built-in variable type of the programming language used by the simulation software, as well as a custom data type related to the simulation business. The variable name is a data identifier, and the organization type is a description of the inclusion and reference relationships between data. The data declaration method is used to determine the changed data that needs to be recorded. The changed data that needs to be persisted in the simulation object tree may change in value after initialization.

3. The simulation process breakpoint read / write method based on data declaration according to claim 1, characterized in that, The response to the simulation interruption instruction includes: an instruction generated in response to a trigger operation of the user interface, an instruction generated by a timed save program, or an instruction generated by the simulation program's exception handling mechanism.

4. The simulation process breakpoint read / write method based on data declaration according to claim 1, characterized in that, The form of the breakpoint data record is consistent with the form of the data declaration. The breakpoint data record is stored in the storage medium using a tree-like organization. The data storage order is consistent with the data declaration. The data declaration is used to describe the storage location of the changed data in the simulation data structure, and is also organized in a tree structure, consistent with the changed data.

5. The simulation process breakpoint read / write method based on data declaration according to claim 1, characterized in that, After restarting the simulation process, the breakpoint record data is read sequentially according to the data declaration structure, and the subsequent simulation process continues from the breakpoint time.

6. The simulation process breakpoint read / write method based on data declaration according to claim 5, characterized in that, The data declaration is organized in a tree structure. Breakpoint data records are traversed using a depth-first algorithm and stored sequentially on storage media such as disks in the form of data files.

7. The simulation process breakpoint read / write method based on data declaration according to claim 6, characterized in that, After restarting the simulation process, the simulation initialization will be performed and some changed data will be assigned. Then, according to the data declaration structure, data will be read sequentially from the breakpoint data file and the simulation object data will be reconstructed in memory.

8. A simulation process breakpoint read / write system based on data declaration, characterized in that, include: The data declaration module is used to pre-configure data declarations; The breakpoint saving module is used to pause the simulation process in response to the simulation interruption command during the simulation run. Based on the tree structure of the data declaration, it uses a depth-first traversal algorithm to extract the values ​​of the corresponding changed data from the simulation object tree in memory and writes them sequentially to the storage medium to generate breakpoint data. The breakpoint reading module is used to load the breakpoint data after restarting the simulation process and performing simulation initialization, read the breakpoint data in sequence according to the structure of the data declaration, and assign the data to the corresponding position in the re-initialized simulation object tree so as to continue the simulation process from the breakpoint.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the data declaration-based simulation process breakpoint read / write method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the data declaration-based simulation process breakpoint read / write method as described in any one of claims 1 to 7.

Images