A flight control simulation scheduling method, device and equipment and storage medium

Abstract

This application discloses a flight control simulation scheduling method, apparatus, device, and storage medium. The method includes: recursively scanning a preset algorithm plugin directory, parsing metadata, and performing memory registration to generate a memory capability registry; obtaining the execution stage information and context data of the current project, and matching it to obtain the target plugin metadata; performing pre-verification and serialization of the context data to generate a standard input file; integrating relevant information to create an algorithm subprocess; asynchronously monitoring, managing timeouts, and recording the lifecycle of the algorithm subprocess to obtain operational diagnostic information; and finally, performing existence checks, structure verification, and result deserialization on the output file, and performing exception isolation to obtain the simulation scheduling execution result. This application supports multi-language plugins, achieves non-intrusive hot-plugging, completely blocks crash propagation, and significantly improves the robustness and algorithm iteration efficiency of the flight control simulation platform.

Description

Technical Field

[0001] This application relates to the field of flight control simulation technology, and in particular to a flight control simulation scheduling method, device, equipment and storage medium. Background Technology

[0002] With the continuous improvement of aerospace equipment development capabilities, the design and verification complexity of control laws for flight control systems is constantly increasing. The flight control law simulation process encompasses multiple core stages, including trim calculations, linearization analysis, and time-frequency domain verification. This requires the comprehensive integration of heterogeneous algorithm tools across multiple languages, such as high-performance numerical solvers based on C++, scripting analysis tools based on Python, graphical control law models based on Simulink, and various self-developed or third-party dedicated solvers. However, existing integration methods for these heterogeneous algorithm tools have numerous drawbacks, severely impacting the operational stability and algorithm iteration efficiency of the flight control simulation platform.

[0003] Current heterogeneous algorithm integration typically employs either dynamic library loading or shared memory solutions. Dynamic library loading compiles each algorithm into a dynamic link library for direct invocation by the main program. However, this approach suffers from issues such as cross-language memory model conflicts, algorithm crashes infecting the main program and causing global system crashes, inconsistent interface specifications leading to high integration costs, and the need for recompilation and coupling testing upon algorithm replacement. Shared memory solutions transfer data through shared memory segments on the operating system, but these suffer from drawbacks such as race conditions in high-concurrency scenarios, poor cross-Windows / Linux platform compatibility, and residual orphan locks or dirty data polluting subsequent computations after abnormal process exits. Furthermore, C++ plugin segmentation faults can cause host process exits; Python plugin dependency conflicts can lead to interpreter errors; Simulink solver failures can result in no output; and residual dirty data in shared memory can cause errors in subsequent task reads.

[0004] Therefore, how to achieve robust scheduling, process-level isolation, dynamic non-intrusive registration, and reliable result recycling of multilingual heterogeneous algorithm plugins, and completely solve the problems of crash contagion, interface inconsistency, high cost of algorithm replacement, and unstable cross-platform operation, is a technical problem that urgently needs to be solved in the field of flight control simulation. Summary of the Invention

[0005] In view of this, the flight control simulation scheduling method, apparatus, device, and storage medium provided in this application can achieve robust scheduling, process-level isolation, dynamic non-intrusive registration, and reliable result recycling of multi-language heterogeneous algorithm plugins, completely solving the problems of crash contagion, interface inconsistency, high algorithm replacement cost, and cross-platform instability. The flight control simulation scheduling method, apparatus, device, and storage medium provided in this application are implemented as follows: This application provides a flight control simulation scheduling method, including: The preset algorithm plugin directory is recursively scanned, metadata parsed, and memory registration is performed to obtain the memory capability registry. Obtain the execution phase information and context data of the current project, and match the execution phase information with the memory capability registry to obtain the target plugin metadata; The context data and the target plugin metadata are pre-verified and serialized to obtain a standard input file; The target plugin metadata, the standard input file, and the working directory path are integrated and processed to create an algorithm subprocess. Asynchronous monitoring, timeout management, and lifecycle recording are performed on the metadata of the algorithm subprocess and the target plugin to obtain subprocess runtime diagnostic information. The existence check, structure verification, result deserialization, and anomaly isolation processes are performed on the algorithm subprocess, the target plugin metadata, and the subprocess runtime diagnostic information to obtain the simulation scheduling execution result.

[0006] In some embodiments, the recursive scanning, metadata parsing, and memory registration processing of a preset algorithm plugin directory to obtain a memory capability registry includes: A recursive scan of the preset algorithm plugin directory is performed to obtain the plugin metadata file; The plugin metadata file is parsed to obtain plugin information, which includes a unique plugin identifier, applicable stage, execution command, input / output structure definition, timeout threshold, and version information. The plugin information is processed for memory storage to obtain an initial memory capacity registry. The initial memory capability registry is lazily loaded and refreshed to obtain the memory capability registry.

[0007] In some embodiments, obtaining the execution phase information and context data of the current project, and matching the execution phase information with the memory capability registry to obtain the target plugin metadata includes: The current project's running status is read and processed to obtain the current project's execution stage information; The working condition parameters, model file path, aerodynamic parameter file path, and user configuration parameters corresponding to the current project execution stage are integrated and processed to obtain project context data; The execution stage information of the current project is matched with the plugin applicable stage information in the memory capability registry to obtain a list of applicable algorithm plugins; The list of applicable algorithm plugins is automatically matched to obtain the target plugin; The registration information of the target plugin is extracted and processed to obtain the target plugin metadata.

[0008] In some embodiments, the pre-verification and serialization of the context data and the target plugin metadata to obtain a standard input file includes: The target plugin metadata is processed to extract the input structure, resulting in the input data structure definition. Perform a pre-structure verification process on the context data and the input data structure definition to obtain context data that passes the verification; The validated context data is subjected to structured serialization to obtain temporary text data; The temporary text data is written to a temporary file to obtain a temporary input file; The temporary input file is subjected to disk data synchronization processing to obtain a temporary input file with complete data; The temporary input file containing the complete data is atomically renamed to obtain the standard input file.

[0009] In some embodiments, the process of integrating and creating a process from the target plugin metadata, the standard input file, and the working directory path to obtain an algorithm subprocess includes: The target plugin metadata is processed to extract execution commands, thereby obtaining the plugin execution commands; The process startup command is obtained by concatenating the command to be executed by the plugin, the absolute path of the standard input file, and the working directory path. The process startup instruction is adapted for cross-platform system calls to obtain the process creation interface call. The process creation interface call is executed to obtain an initial child process; The initial subprocess is isolated in an independent address space to obtain the algorithm subprocess.

[0010] In some embodiments, the asynchronous monitoring, timeout management, and lifecycle recording of the algorithm subprocess and the target plugin metadata to obtain subprocess runtime diagnostic information includes: The target plugin metadata is subjected to timeout threshold extraction processing to obtain the process timeout threshold; The startup time of the algorithm's subprocess is recorded to obtain the process startup timestamp; The process start timestamp and the process timeout threshold are configured to generate a process timeout timer. The running status of the algorithm's subprocesses is asynchronously polled to obtain the real-time status information of the subprocesses; The real-time status information of the subprocess is compared with the process timeout timer. If the runtime of the real-time status information of the subprocess exceeds the timing threshold of the process timeout timer, the algorithm subprocess is forcibly terminated and information is collected to obtain the basic running information of the subprocess. The basic runtime information of the subprocess is integrated with the process standard output and standard error stream log to obtain subprocess runtime diagnostic information.

[0011] This application provides a flight control simulation scheduling device, comprising: The processing module is used to recursively scan the preset algorithm plugin directory, parse metadata, and perform memory registration to obtain the memory capability registry. The acquisition module is used to acquire the execution stage information and context data of the current project, and to match the execution stage information with the memory capability registry to obtain the target plugin metadata. The processing module is also used to perform pre-verification and serialization processing on the context data and the target plugin metadata to obtain a standard input file; The processing module is also used to integrate and process the target plugin metadata, the standard input file, and the working directory path to obtain an algorithm subprocess; The processing module is also used to asynchronously monitor, manage timeouts, and record lifecycle data of the algorithm subprocess and the target plugin metadata to obtain subprocess running diagnostic information; The verification module is used to perform existence checks, structure verification, result deserialization, and anomaly isolation on the algorithm subprocess, the target plugin metadata, and the subprocess runtime diagnostic information to obtain the simulation scheduling execution result.

[0012] The computer device provided in this application includes a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements the method described in this application.

[0013] The computer-readable storage medium provided in this application embodiment stores a computer program thereon, which, when executed by a processor, implements the method described in this application embodiment.

[0014] The flight control simulation scheduling method, apparatus, device, and storage medium provided in this application embodiment utilize JSONSchema input to detect missing fields / incorrect types before process creation; temporary files + fsync + atomic renaming prevent child processes from reading partially written files; independent processes and non-shared memory prevent segmentation faults from corrupting the main program's address space; timeout forced termination transforms infinite loops into bounded failures; and output existence checks and structure verification make failures diagnosable and traceable. A memory capability registry is generated by recursively scanning, parsing metadata, and registering memory in a preset algorithm plugin directory; the execution stage information and context data of the current project are obtained, and the target plugin metadata is matched; the context data is pre-verified and serialized to generate a standard input file; relevant information is integrated to create algorithm subprocesses; asynchronous monitoring, timeout management, and lifecycle recording of the algorithm subprocesses are performed to obtain operational diagnostic information; finally, the output file undergoes existence checks, structure verification, and result deserialization, and exception isolation is performed to obtain the simulation scheduling execution result. In this way, robust scheduling, process-level isolation, dynamic non-intrusive registration, and reliable result recycling of multilingual heterogeneous algorithm plugins can be achieved, completely solving the problems of crash contagion, interface inconsistency, high cost of algorithm replacement, and instability in cross-platform operation, thus solving the technical problems proposed in the background technology. Attached Figure Description

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

[0016] Figure 1 A schematic diagram illustrating the implementation process of a flight control simulation scheduling method provided in this application embodiment; Figure 2 A schematic diagram illustrating the implementation process of obtaining a registry for memory capabilities, provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a flight control simulation scheduling device provided in an embodiment of this application. Detailed Implementation

[0017] 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 invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0018] The following description of some technologies involved in the embodiments of this application is provided to aid understanding and should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, some descriptions of well-known functions and structures are omitted in the following description.

[0019] Figure 1 This is a schematic diagram illustrating the implementation flow of a flight control simulation scheduling method provided in this application embodiment, including steps 101 to 106. Wherein, Figure 1 This is merely one execution order shown in the embodiments of this application and does not represent the only execution order of a flight control simulation scheduling method. Where the final result can be achieved, Figure 1 The steps shown can be performed in parallel or in reverse order.

[0020] Step 101: Recursively scan, parse metadata, and register memory in the preset algorithm plugin directory to obtain the memory capability registry.

[0021] In this embodiment, when the system starts up or receives a plugin refresh command, it recursively traverses the pre-configured algorithm plugin root directory and its subdirectories to identify all plugin metadata files that conform to preset naming rules. The plugin metadata file is a plugin_meta.json file; files with other formats or names are skipped. The identified plugin metadata files are parsed and required fields are validated to extract complete plugin information. The plugin information includes: plugin_id field (unique plugin identifier), display_name field (plugin display name), applicable_stages field (applicable flight control design stage), execution_cmd field (execution command), runtime_env field (running environment requirements), input_schema field (input JSONSchema, i.e., input data structure definition), output_schema field (output JSONSchema, i.e., output data structure definition), timeout_sec field (process timeout threshold), and version field (version information).

[0022] If a metadata file fails to parse or is missing any of the required fields, the system generates a registration failure log and skips the registration of the corresponding plugin, without affecting the registration process of other plugins. Plugin information that passes format parsing and required field validation is stored in system memory as key-value pairs, generating an initial memory capability registry. The key is a unique identifier for the plugin, and the value is a complete set of information corresponding to that plugin.

[0023] The initial memory capability registry is managed using a lazy loading method. At system startup, only the metadata information of the plugins is loaded; no plugin executable code or runtime environment is preloaded. Only when the current flight control simulation project enters the target flight control design phase does the system query the memory capability registry for the appropriate set of algorithm plugins based on that target flight control design phase, avoiding unnecessary system resource overhead. A plugin refresh trigger mechanism is also configured. When a user triggers a plugin refresh command, the system rescans the algorithm plugin directory and updates the memory capability registry, allowing plugin addition, modification, and deletion to be completed without restarting the main program.

[0024] Step 102: Obtain the execution phase information and context data of the current project, match the execution phase information with the memory capability registry, and obtain the target plugin metadata.

[0025] In this embodiment, the flow cursor or status flag of the current flight control simulation project is read to obtain the execution stage information of the current project. The applicable flight control design stage includes at least one of the following: trim calculation stage, small disturbance linearization stage, time domain response analysis stage, frequency domain response analysis stage, and robustness analysis stage. If the project is in an inactive state, the system displays all available plugins for the user to select by default.

[0026] The system integrates and processes the operating parameters, model file paths, aerodynamic parameter file paths, and user configuration parameters corresponding to the current execution stage of the project to obtain project context data. Operating parameters include flight state vectors, atmospheric environment parameters, and control input constraints; model file paths include the absolute paths to flight dynamics model files and control law model files, supporting multiple formats such as .slx, .py, and .so; aerodynamic parameter file paths include the absolute paths to aerodynamic interpolation tables and aerodynamic coefficient matrix files, supporting formats such as .mat and .h5; and user configuration parameters include simulation step size, convergence accuracy, and output accuracy set by the user on the interface.

[0027] The system iterates through the memory capability registry, matching the current project's execution stage information with the applicable flight control design stages in the metadata of each plugin to obtain a list of applicable algorithm plugins. A runtime environment pre-check is performed on all algorithm plugins in the list to determine if the current computer device meets the interpreter version, dependency library version, or executable file path requirements declared by the corresponding plugin. Based on the runtime environment pre-check results and version information, the list of applicable algorithm plugins is sorted according to the rule of "runtime environment compliance priority, highest version number priority," and the plugin ranked first is automatically selected as the target plugin; if multiple matching plugins exist, the user can also manually select the target plugin. The registration information of the selected target plugin is extracted and processed to obtain complete target plugin metadata.

[0028] The algorithm plugins include at least one of the following: C++ executable plugins, Python script plugins, MATLAB / Simulink model wrapper plugins, and third-party solver wrapper plugins.

[0029] Step 103: Perform pre-verification and serialization processing on the context data and target plugin metadata to obtain the standard input file.

[0030] In this embodiment of the application, the target plugin metadata is processed by input structure extraction to obtain the input data structure definition, namely the input JSONSchema. This definition includes the name, data type, whether it is required, the valid range of values, array dimensions, and nested structure definition of all input fields.

[0031] The project context data undergoes preliminary structure validation based on the input JSONSchema. Specifically, this includes: verifying the existence of required fields in the project context data; verifying whether the field types in the project context data conform to the data types declared in the input JSONSchema; and verifying whether the numeric fields in the project context data conform to the value range or array dimensions declared in the input JSONSchema. If any validation item fails, a preliminary validation failure message containing the error field, error type, and error reason is generated, the creation of the algorithm subprocess is refused, and the current task is terminated. If all validation items pass, validated context data is obtained.

[0032] The validated project context data is serialized into a standard JSON string. A temporary input file with a random name is created in the dedicated working directory corresponding to the current simulation task, and the JSON string is written to this temporary input file. After writing, the operating system's disk data synchronization interface is called to force all data in the file system cache to be written to the physical disk, resulting in a complete temporary input file. The temporary input file after disk data synchronization is atomically renamed to obtain the standard input JSON file, ensuring that the input file read by subsequent algorithm subprocesses is always complete and undamaged.

[0033] Step 104: Integrate and process the target plugin metadata, standard input file, and working directory path to obtain the algorithm subprocess.

[0034] In this embodiment, the target plugin metadata is processed to extract executable commands, resulting in the plugin's executable commands. The absolute path of the plugin's executable command, the standard input file, and the dedicated working directory path are concatenated to generate a complete process startup instruction. Cross-platform system call adaptation is performed on the process startup instruction: the corresponding process creation interface is called in the Windows operating system, and the process forking and execution system call is called in the Linux operating system, generating a unified process creation interface call. Executing this process creation interface call generates an initial child process. After calling the operating system's process creation interface, the operating system allocates an independent virtual address space for the algorithm child process. The main program does not load the target plugin algorithm dynamic library through dlopen / LoadLibrary or other methods, nor does it establish a shared memory segment with the algorithm child process. Instead, it only exchanges data through the standard input file, environment variables, and working directory, giving the child process an independent memory address space. It does not share any memory segment with the main program, and runtime exceptions within the child process do not propagate to the main program, ultimately resulting in an algorithm child process running in an independent address space.

[0035] Therefore, when a C++ plugin experiences a segmentation fault, a Python plugin interpreter error, or a Simulink solver failure, the failure manifests on the main program side as a missing process exit code, termination method, standard error log, or output file, rather than as a corruption of the main program's address space.

[0036] Step 105: Asynchronously monitor, manage timeouts, and record lifecycle data of the algorithm subprocess and target plugin to obtain subprocess running diagnostic information.

[0037] In this embodiment, timeout threshold extraction is performed on the target plugin metadata to obtain the process timeout threshold. The startup time of the algorithm subprocess is recorded to obtain the process startup timestamp. The process startup timestamp and the process timeout threshold are configured to generate a process timeout timer. The running status of the algorithm subprocess is periodically and asynchronously polled to obtain the running status information of the subprocess in real time. The real-time status information of the subprocess is compared with the process timeout timer. When the running time of the subprocess exceeds the preset timeout threshold, a forced termination signal is sent to the algorithm subprocess to terminate its operation. The termination time, termination method, and process exit code of the algorithm subprocess are collected to obtain the basic running information of the subprocess. The termination methods include normal exit, timeout termination, and abnormal crash. A process exit code of 0 indicates successful execution, and a non-zero value indicates failure. The basic running information of the subprocess is integrated with the standard output and standard error stream logs generated during the subprocess's operation to obtain complete subprocess running diagnostic information. Therefore, infinite loops in algorithm subprocesses, long-term non-convergence of the solver, or external interpreter freezing will not occupy the process engine indefinitely; the scheduler will convert such failures into timeout failure events with termination time, termination method, and log evidence.

[0038] Step 106: Perform output file existence checks, structure verification, result deserialization, and anomaly isolation on the algorithm subprocess, target plugin metadata, and subprocess runtime diagnostic information to obtain the simulation scheduling execution result.

[0039] In this embodiment, after the algorithm subprocess terminates, the scheduler first extracts the output structure definition, expected output file name, and expected output file format from the target plugin metadata, and determines the expected output file path based on the dedicated working directory corresponding to the current simulation task. The expected output file may include at least one of output.json, output.mat, or output.h5.

[0040] Specifically, the scheduler reads the subprocess runtime diagnostic information, which includes the task identifier, plugin unique identifier, execution stage identifier, process identifier, process start time, process termination time, termination method, process exit code, standard output log path, and standard error log path. The termination methods include normal exit, timeout termination, and abnormal exit.

[0041] Furthermore, the scheduler performs an existence check on the expected output file path to determine the output file's existence status. Based on the output file's existence status, termination method, and process exit code, task failures are categorized into at least the following three types: The first type of failure is abnormal exit or timeout termination with missing output. If the algorithm subprocess terminates abnormally or timeout, or if the process exit code of the algorithm subprocess is non-zero, and the expected output file does not exist in the dedicated working directory, the scheduler generates the first type of output missing diagnostic information. The first type of output missing diagnostic information includes at least the task identifier, plugin unique identifier, execution stage identifier, termination method, process exit code, standard error log path, expected output file path, output file existence status, and failure classification identifier. The failure classification identifier indicates that the current failure is due to process abnormality or timeout causing output missing. The scheduler marks the current simulation task as a failure, freezes the flow cursor corresponding to the current simulation task, releases the running resources corresponding to the algorithm subprocess, and writes the first type of output missing diagnostic information to the project audit log; at the same time, the main program and other parallel simulation tasks continue to run.

[0042] The second type of failure is a normal exit with missing output. If the algorithm subprocess terminates normally and the process exit code indicates successful execution, but the expected output file does not exist in the dedicated working directory, the scheduler generates second-type output missing diagnostic information. This second-type output missing diagnostic information includes at least the task identifier, plugin unique identifier, execution stage identifier, process exit code, expected output file path, output file existence status, standard output log path, and failure classification identifier. The failure classification identifier indicates that the current failure is due to the plugin completing execution but failing to generate the expected output file according to the output contract. The scheduler marks the current simulation task as an output missing failure, freezes the process cursor corresponding to the current simulation task, and writes the second-type output missing diagnostic information to the project audit log; simultaneously, it does not report the intermediate results of this task to the process engine to prevent subsequent flight control simulation stages from continuing execution based on missing or incomplete results.

[0043] The third type of failure occurs when the output file exists but the structure validation fails. If the expected output file exists in the dedicated working directory, the scheduler reads the expected output file and performs structure validation. For the output.json file, the scheduler validates output.json based on the output JSONSchema in the target plugin metadata. The validation includes the existence of required fields, field type matching, numerical range compliance, and array dimension consistency. For output.mat or output.h5 files, the scheduler performs file header magic number validation and basic structure parsing validation. When the expected output file fails the structure validation, the scheduler generates output structure anomaly diagnostic information. The output structure anomaly diagnostic information includes at least the task identifier, plugin unique identifier, execution stage identifier, expected output file path, validation type, validation failure field path, expected data type, actual data type, validation failure reason, and failure category identifier. The scheduler marks the current simulation task as a validation failure state, freezes the process cursor corresponding to the current simulation task, and writes the output structure anomaly diagnostic information to the project audit log; at the same time, it does not deserialize the output file that fails validation into an internal data object to avoid abnormal output polluting subsequent simulation processes.

[0044] If the expected output file exists and passes the structure verification, the scheduler deserializes the expected output file, converts the output content into an internal data object that the flight control simulation platform can recognize, and reports the internal data object to the process engine to trigger subsequent compliance assessment or process advancement logic.

[0045] By differentiating and handling the three types of failure modes mentioned above, the scheduler can distinguish between three different failure causes: missing output due to process abnormalities, normal plugin exit without generating output files, and output files existing but whose content does not conform to the data contract. At the same time, the scheduler only freezes the process cursor corresponding to the currently failed task, without changing the running state of the main program and the execution state of other parallel simulation tasks, thereby achieving task-level exception isolation and traceable diagnosis.

[0046] This application embodiment achieves non-intrusive integration of multi-language heterogeneous algorithm plugins through a metadata-driven dynamic registration mechanism, allowing algorithms to be added or replaced without modifying the main program code. Under the above processing, plugin failure will not directly cause the main program process to exit. Failed tasks are recorded as a diagnostic report containing plugin ID, task ID, execution stage, exit code, termination method, standard error log, expected output file path, and verification failure field. The process engine only freezes the process cursor corresponding to the failed task, while other parallel tasks continue to execute.

[0047] In the above Figure 1Based on the above, this application embodiment also provides a schematic diagram of the implementation process for obtaining the memory capability registry. For example... Figure 2 As shown, steps 201 to 204 are included: Step 201: Perform a recursive scan of the preset algorithm plugin directory to obtain the plugin metadata file.

[0048] In this embodiment, the system automatically performs an initial scan upon startup, or performs an incremental scan when the user manually triggers a "plugin refresh" operation. The root directory path of the algorithm plugin is pre-set in the system configuration file. During the scan, this root directory and all its subdirectories are traversed layer by layer. During the traversal, files with filenames conforming to a preset naming convention are identified. Only files named "plugin_meta.json" are considered plugin metadata files; files with other formats or names are skipped. Finally, all valid plugin metadata files are collected. Step 202 involves parsing the plugin metadata files to obtain plugin information, including a unique plugin identifier, applicable stage, execution command, input / output structure definition, timeout threshold, and version information.

[0049] In this embodiment, the contents of each plugin metadata file are read sequentially, and the fields are parsed according to a preset JSON format to extract complete plugin information. Plugin information includes: a globally unique plugin identifier string (plugin_id field), the plugin display name (display_name field), an array of flight control design stages applicable to the plugin (applicable_stages field), an executable command string to start the plugin (execution_cmd field), a description of the environment required for plugin operation (runtime_env field), a standardized definition of the input data structure (input_schema field, i.e., input JSONSchema), a standardized definition of the output data structure (output_schema field, i.e., output JSONSchema), a timeout threshold in seconds for plugin execution (timeout_sec field), and the plugin version number (version field). If a metadata file fails to parse or is missing a required field, the system skips that plugin and records the parsing error information in the diagnostic log, without affecting the registration process of other plugins. Step 203: The plugin information is processed for memory storage to obtain an initial memory capacity registry.

[0050] In this embodiment, all successfully parsed plugin information is stored in system memory as key-value pairs, where the key is a unique identifier for the plugin and the value is a complete set of information corresponding to that plugin. After all plugin information is stored, an initial memory capability registry is formed. This registry serves as a global plugin capability resource pool for subsequent process engines to query and access.

[0051] Step 204: Perform lazy loading configuration and refresh triggering on the initial memory capability registry to obtain the memory capability registry.

[0052] In this embodiment, a lazy loading configuration is enabled for the initial memory capability registry. At system startup, only the metadata information of the plugins is loaded; no plugin executable code or runtime environment is preloaded. Only when the process engine needs to execute a task in a specific flight control design phase will it query the registry for the appropriate plugin set for that phase, avoiding unnecessary system resource overhead. Simultaneously, a plugin refresh trigger mechanism is configured. When a user triggers a refresh operation, the system re-executes a recursive scan of the plugin directory and metadata parsing, compares the differences between the old and new registry entries, and automatically completes the registration of new plugins, updates the information of existing plugins, and deregisters deleted plugins. The entire update process does not require restarting the main program, achieving non-intrusive hot updates of plugins, ultimately resulting in a dynamically updated memory capability registry.

[0053] This application embodiment automatically discovers all compliant plugins by recursively scanning the plugin directory, eliminating the need for manual plugin path configuration. Standardized metadata parsing unifies the description methods for different types of plugins, enabling unified management of plugin capabilities. Storing plugin information in memory creates a globally queryable capability registry, ensuring rapid plugin matching. Lazy loading configurations only query corresponding plugins when needed, avoiding unnecessary system resource overhead. A refresh trigger mechanism supports hot updates of plugins without restarting, allowing plugin addition, modification, and deletion without interrupting the main program, greatly improving the maintainability of the simulation platform.

[0054] In some embodiments, the execution phase information and context data of the current project are obtained, and the execution phase information is matched with the memory capability registry to obtain the target plugin metadata, including: reading the running status of the current project to obtain the execution phase information of the current project.

[0055] Specifically, the system reads the project's flow cursor and status flags from the root directory configuration file of the flight control simulation project to determine the current execution stage of the project. The execution stages include five core flight control design stages: trim calculation, small disturbance linearization, time-domain response analysis, frequency-domain characteristic analysis, and robustness analysis. Each stage corresponds to different algorithm calculation requirements. If the project is not started, the system displays all available plugins for the user to select from by default.

[0056] Furthermore, the working condition parameters, model file paths, aerodynamic parameter file paths, and user configuration parameters corresponding to the current execution stage of the project are integrated and processed to obtain project context data.

[0057] Specifically, the core data required for the current execution phase is extracted from the engineering database: operating parameters include flight state vectors, atmospheric environmental parameters, control input constraints, etc.; model file paths include the absolute paths of flight dynamics model files and control law model files, supporting multiple formats such as .slx, .py, and .so; aerodynamic parameter file paths include the absolute paths of aerodynamic interpolation tables and aerodynamic coefficient matrix files, supporting formats such as .mat and .h5; user configuration parameters include simulation step size, convergence accuracy, output accuracy, etc., set by the user on the interface. All the above data are integrated in a unified structured format to form complete engineering context data.

[0058] Furthermore, the execution phase information of the current project is matched with the plugin applicable phase information in the memory capacity registry to obtain a list of applicable algorithm plugins.

[0059] Specifically, the system iterates through all registered plugins in the memory capability registry, extracts the applicable stage information for each plugin, and compares it one by one with the execution stage information of the current project. If a plugin's applicable stage array contains the execution stage of the current project, then the plugin is added to the applicable algorithm plugin list. If no matching plugin is found in the memory capability registry, the system generates a "No available plugin" message and terminates the current task, without affecting the main program or the operation of other projects.

[0060] Furthermore, the list of applicable algorithm plugins is automatically matched to obtain the target plugin.

[0061] Specifically, the system sorts the list of applicable algorithm plugins according to preset priority rules: plugins with the highest version numbers are selected first; if the version numbers are the same, plugins that have passed the runtime environment test are selected first, i.e., plugins whose interpreter version and dependency library list declared in their metadata match the current system environment. After sorting, the system automatically selects the top-ranked plugin as the target plugin. If the user needs to select manually, the system will display detailed information about the list of applicable algorithm plugins, including plugin name, version number, runtime environment requirements, etc., allowing the user to manually select the target plugin.

[0062] Furthermore, the registration information of the target plugin is extracted and processed to obtain the target plugin metadata.

[0063] Specifically, all registration information corresponding to the target plugin is extracted from the memory capability registry, including the plugin's unique identifier, plugin display name, applicable stage, execution command, runtime environment requirements, input data structure definition, output data structure definition, timeout threshold, and version information, forming complete target plugin metadata, which provides the core basis for subsequent input validation, process creation, monitoring management, and result validation steps.

[0064] This application's embodiments automatically read the execution stage information of the current project, eliminating the need for users to manually specify the required algorithm type; by integrating all core data of the current execution stage to form unified project context data, the integrity and consistency of input data are guaranteed; by matching the execution stage information with the applicable stage of the plugin, all plugins suitable for the current task can be automatically selected, avoiding errors from manual selection; through an automatic matching mechanism with preset priorities, the optimal target plugin can be quickly selected, improving the execution efficiency of the simulation task; by extracting the complete metadata of the target plugin, a unified basis is provided for all subsequent steps such as input verification, process creation, monitoring management, and result verification, ensuring the consistency of the entire process.

[0065] In some embodiments, pre-validation and serialization processing of context data and target plugin metadata are performed to obtain a standard input file, including: extracting the input structure from the target plugin metadata to obtain an input data structure definition.

[0066] Specifically, predefined input data structure description information is extracted from the target plugin's metadata. This information contains complete specifications for all input fields required for plugin execution, including the name, data type, whether it is a required field, valid range of values, array dimensions, and nested structure definition for each field. The input data structure definition is the sole basis for subsequent data validation and serialization, ensuring that the input data fully conforms to the target plugin's format requirements.

[0067] Furthermore, a pre-structure validation process is performed on the context data and input data structure definitions to obtain the validated context data.

[0068] Specifically, the project context data is validated layer by layer according to the input data structure definition: First, all required fields are checked to ensure they exist and are not empty; second, the data type of each field is verified to be consistent with the definition, for example, numeric fields cannot be string types; finally, the values ​​of numeric fields are verified to be within the preset valid range. If any validation fails, the system generates detailed log information including the specific error field, error type, and error reason, terminates the current task, and returns an error message. This error will not affect the operation of the main program and other parallel tasks. If all validation items pass, the validated context data is obtained.

[0069] Furthermore, the validated context data is subjected to structured serialization processing to obtain temporary text data.

[0070] Specifically, the validated context data is converted into uniform structured text data according to the field order and format requirements defined in the input data structure. The serialization process strictly follows the input data structure definition, preserving the hierarchical relationships and data type information of all fields to ensure that the target plugin can accurately parse the input data.

[0071] Furthermore, the temporary text data is written to a temporary file to obtain a temporary input file.

[0072] Specifically, in the dedicated working directory created for this task, a temporary file with a random name is generated, and the structured temporary text data is completely written into this temporary file. Using a random filename avoids file naming conflicts between different tasks and ensures that the input files for each task are independent.

[0073] Furthermore, disk data synchronization processing is performed on the temporary input file to obtain a complete temporary input file.

[0074] Specifically, after the temporary file is written, the operating system's disk data synchronization interface is called to force all data in the file system cache to be written to the physical disk. This operation prevents incomplete file data due to the system cache not being refreshed, ensuring that all content of the temporary input file is persistently stored.

[0075] Furthermore, the temporary input file with complete data is atomically renamed to obtain the standard input file.

[0076] Specifically, the temporary input file with complete data is renamed to the preset standard input file name. This renaming operation is atomic at the operating system level, meaning it either succeeds completely or fails completely, with no intermediate states. Through this atomic renaming operation, it is guaranteed that subsequent algorithm subprocesses will always read a complete input file, avoiding incomplete files that are still being written, ultimately resulting in a standard input file that meets the requirements.

[0077] This application provides a clear standard for data verification and serialization by extracting the input data structure definition of the target plugin. Pre-processing structure verification can detect data loss, type errors, or out-of-bounds values ​​before computation begins, avoiding unnecessary consumption of computational resources. Structured serialization converts engineering data from different sources and in different formats into a unified standard format, achieving unified data adaptation for heterogeneous algorithms. Disk data synchronization and atomic renaming operations fundamentally solve the problem of incomplete data during file writing, ensuring that the input files read by the algorithm subprocesses are always complete and correct, effectively preventing computational failures due to corrupted input files.

[0078] In some embodiments, the target plugin metadata, standard input file, and working directory path are integrated and process-created to obtain an algorithm subprocess, including: extracting execution commands from the target plugin metadata to obtain plugin execution commands.

[0079] Specifically, a predefined plugin startup command string is extracted from the target plugin metadata. This command string contains the path to the plugin executable file and basic runtime parameters. For example, for a Python script plugin, the execution command is the absolute path to the corresponding Python interpreter; for a C++ compiled executable plugin, the execution command is the absolute path to the executable file; and for an executable model generated by Simulink, the execution command is the path to the executable file corresponding to the model.

[0080] Furthermore, the absolute path of the plugin execution command, the standard input file, and the working directory path are concatenated to obtain the process startup command.

[0081] Specifically, the absolute path of the standard input file and the path of the custom working directory are added as parameters to the end of the plugin's execution command to form a complete process startup instruction. The parameter concatenation process strictly adheres to the target plugin's parameter format requirements to ensure that the plugin can correctly recognize and read the input file path and working directory path. For example, the concatenated process startup instruction might be: "python3 / plugins / linearization.py --input / workspace / task123 / input.json --workdir / workspace / task123".

[0082] Furthermore, the process startup instruction is adapted for cross-platform system calls to obtain the process creation interface call.

[0083] Specifically, the system automatically detects the currently running operating system and selects the appropriate process creation system call based on the operating system. In Windows, the process startup instruction is converted into the parameter format of the corresponding process creation system call; in Linux, the process startup instruction is converted into the parameter format of the process forking and execution system calls. Through cross-platform adaptation, the same scheduling logic can run seamlessly on different operating systems.

[0084] Furthermore, the process creation interface call is executed to obtain the initial child process.

[0085] Specifically, the process creation interface provided by the operating system is invoked to execute the process startup instruction, creating a new operating system process, i.e., the initial child process. After the initial child process is successfully created, the operating system allocates an independent process ID, file descriptor table, and system resource quota to it.

[0086] Furthermore, the initial child process is isolated in an independent address space to obtain the algorithm child process.

[0087] Specifically, when the operating system creates the initial child process, it automatically allocates an independent virtual address space for it. This address space is completely isolated from the main program's address space, with no shared memory areas between them. All memory operations of the child process are performed within its own address space. Even if the child process encounters a memory access error, null pointer exception, or crash, it will not affect the main program's memory space or running state. Through this process-level address space isolation mechanism, the propagation path from plugin crashes to the main program is completely blocked, ultimately resulting in an algorithm child process running in an independent address space.

[0088] This application's embodiments automatically extract plugin execution commands and concatenate parameters, eliminating the need for users to manually write complex startup scripts. Through cross-platform system call adaptation, it achieves seamless operation of the same scheduling logic on Windows and Linux operating systems, improving the cross-platform compatibility of the simulation platform. By creating algorithm subprocesses running in independent address spaces, there is absolutely no memory sharing between the subprocesses and the main program, completely blocking the propagation path of plugin memory errors, null pointer exceptions, and other problems to the main program. This fundamentally solves the crash propagation problem existing in current dynamic library loading schemes, greatly improving the stability and reliability of the entire simulation system.

[0089] In some embodiments, asynchronous monitoring, timeout management, and lifecycle recording are performed on the algorithm subprocess and target plugin metadata to obtain subprocess running diagnostic information, including: extracting timeout thresholds from the target plugin metadata to obtain process timeout thresholds.

[0090] Specifically, a predefined plugin execution timeout threshold is extracted from the target plugin metadata. This threshold, measured in seconds, is the maximum allowable execution time set based on the typical computation time and system performance of different flight control simulation phases. For example, the timeout threshold for the trim calculation phase is typically set to 300 seconds, while the timeout threshold for the linearization analysis phase is typically set to 60 seconds.

[0091] Furthermore, the startup time of the algorithm subprocess is recorded to obtain the process startup timestamp.

[0092] Specifically, the system records the current system timestamp, accurate to the millisecond, at the instant the operating system process creation interface is successfully called to create the algorithm child process. This timestamp serves as the benchmark for subsequent calculations of the child process's runtime and for determining whether a timeout has occurred.

[0093] Furthermore, the process start timestamp and process timeout threshold are configured to generate a process timeout timer.

[0094] Specifically, the system creates an independent timing thread, starting with the process startup timestamp and ending with the process timeout threshold, to generate a process timeout timer. This timer runs independently of the main program's main thread and the algorithm's subprocess, and is not affected by blocking of the main program or subprocess, ensuring the accuracy of the timing.

[0095] Furthermore, the running status of the algorithm subprocesses is asynchronously polled to obtain real-time status information of the subprocesses.

[0096] Specifically, the system uses a dedicated monitoring thread to asynchronously poll the running status of the algorithm's subprocesses at preset 1-second intervals. During polling, the system calls the process status query interface provided by the operating system to obtain the current status of the subprocesses, including running, exited, and suspended. Simultaneously, the system captures the standard output and standard error stream data output by the subprocesses in real time and caches them in memory.

[0097] Furthermore, the real-time status information of the subprocess is compared with the process timeout timer. If the runtime of the subprocess's real-time status information exceeds the timeout threshold of the process timeout timer, the algorithm subprocess is forcibly terminated and information is collected to obtain the basic running information of the subprocess.

[0098] Specifically, the system calculates the difference between the current system time and the process startup timestamp in real time to obtain the child process's runtime. This runtime is then compared to a process timeout threshold: if the runtime is within the threshold and the child process is still running, polling monitoring continues; if the runtime exceeds the threshold, the child process is determined to have timed out, and the system sends a forced termination signal to terminate it. Regardless of whether the child process exits normally, crashes abnormally, or times out, the system immediately collects its termination time, termination method, and process exit code after termination, forming basic runtime information for the child process. Termination methods include normal exit, timeout termination, and abnormal crash; a process exit code of 0 indicates normal completion of the child process, while a non-zero value indicates failure.

[0099] Furthermore, the basic runtime information of the child process is integrated with the process's standard output and standard error stream logs to obtain the child process runtime diagnostic information.

[0100] Specifically, the collected basic runtime information of the subprocesses is integrated with the standard output logs and standard error logs of the subprocesses cached during monitoring, and a complete subprocess runtime diagnostic information is generated according to a unified structured format. This diagnostic information includes a complete lifecycle record of the subprocess from startup to termination, providing a comprehensive basis for subsequent task failure analysis and problem localization.

[0101] This application embodiment uses an independent asynchronous monitoring thread to monitor the status of child processes in real time without blocking the main program, ensuring the responsiveness of the main program. Through a timeout management mechanism based on plugin metadata, reasonable timeout thresholds can be set according to the characteristics of different algorithms, effectively preventing task freezes caused by algorithm infinite loops or computational anomalies. A timeout-forced termination mechanism can promptly release system resources occupied by stuck child processes, avoiding resource leaks. By integrating the basic runtime information of child processes with standard output and standard error logs, complete runtime diagnostic information is generated, providing comprehensive and accurate basis for problem localization and debugging after task failure, significantly improving the debuggability of simulation tasks.

[0102] To further illustrate the task-level isolation and diagnosis effects of the embodiments of this application in scenarios of abnormal heterogeneous flight control algorithm plugins, the embodiments of this application are described below in conjunction with typical fault injection scenarios. The fault injection scenarios described below are only used to illustrate the implementation methods of the embodiments of this application and do not constitute a limitation on the scope of protection of this application.

[0103] Scenario 1: An illegal memory access occurs in the C++ algorithm plugin.

[0104] In one embodiment, the target plugin is a C++ executable plugin. The applicable_stages field in the target plugin metadata includes small perturbation linearization stages, the execution_cmd field points to the startup path of the C++ executable, the input_schema field declares the flight state vector, control input, aerodynamic parameter file path, and model file path required for linearization calculation, and the output_schema field declares the state matrix, input matrix, output matrix, and direct transfer matrix required for the linearization calculation results.

[0105] The scheduler reads the execution phase information of the current flight control simulation project, determines that the current task is a small-disturbance linearization task, and matches the C++ executable program plugin as the target plugin from the memory capability registry. The adaptation layer performs a pre-structure validation on the project context data based on the input_schema field in the target plugin's metadata. After successful validation, the adaptation layer serializes the project context data into a standard input JSON file and writes it to the dedicated working directory corresponding to the current task. Subsequently, the adaptation layer writes the absolute path of the standard input JSON file to the INPUT_FILE environment variable, writes the dedicated working directory path to the WORK_DIR environment variable, and calls the unified process creation interface to start the algorithm subprocess corresponding to the C++ executable program.

[0106] In this embodiment, the main program does not load the C++ algorithm plugin via dynamic library loading, nor does it establish a shared memory segment with the algorithm subprocess. The C++ algorithm plugin performs linearized calculations in the independent process address space of the algorithm subprocess. When the C++ algorithm plugin encounters an illegal memory access during matrix calculation, the operating system terminates the algorithm subprocess; the illegal memory access does not change the address space content of the main program.

[0107] After the scheduler detects the termination of the algorithm subprocess through an asynchronous lifecycle monitoring mechanism, it collects the process identifier, start time, termination time, termination method, process exit code, standard output log, and standard error log of the algorithm subprocess to form subprocess runtime diagnostic information. If the termination method is abnormal exit, or the process exit code is a non-zero value, the scheduler continues to check whether the expected output file of the target plugin metadata declaration exists in the dedicated working directory.

[0108] When the expected output file is not found in the dedicated working directory, the scheduler categorizes the failure as output loss due to abnormal exit and generates first-type output loss diagnostic information. This first-type output loss diagnostic information includes at least the task identifier, plugin unique identifier, execution stage identifier, process identifier, start time, termination time, termination method, process exit code, standard error log path, expected output file path, output file existence status, and failure classification identifier. The failure classification identifier indicates that the current task failed because the algorithm subprocess exited abnormally and the expected output file was not generated.

[0109] When the expected output file exists in the dedicated working directory but the file fails the output_schema check, or the binary output file fails the file header magic number check and basic structure parsing check, the scheduler will not treat the output file as a valid linearization calculation result. Instead, it will generate output structure anomaly diagnostic information and mark the current simulation task as a check failure state.

[0110] For any output loss or abnormal output structure caused by the aforementioned abnormal exit, the scheduler freezes the flow cursor corresponding to the current simulation task, writes the diagnostic information to the project audit log, and prohibits the reporting of missing or failed validation results to the flow engine. The main program continues to run during this process, and the processes, working directories, and flow cursors of other parallel simulation tasks remain unchanged. Thus, illegal memory access by the C++ algorithm plugin is restricted to the current algorithm subprocess and the current simulation task, and is converted into traceable task failure diagnostic information.

[0111] Scenario 2: The Python algorithm plugin gets stuck in an infinite loop.

[0112] In one embodiment, the target plugin is a Python script plugin, applicable to either the robustness analysis phase or the Monte Carlo analysis phase. The scheduler configures a timeout timer based on the `timeout_sec` field in the target plugin's metadata and starts the corresponding algorithm subprocess of the Python algorithm plugin. This Python algorithm plugin may fail to exit for an extended period during iterative computation due to an incorrect convergence condition configuration.

[0113] In this embodiment, the scheduler periodically and asynchronously polls the running status of the algorithm subprocess. When the runtime of the algorithm subprocess exceeds the timeout threshold corresponding to the timeout_sec field and still has not exited, the scheduler sends a forced termination signal to the algorithm subprocess and collects the process termination time, termination method, process exit code, standard output log, and standard error log. If the expected output file does not exist in the dedicated working directory, the scheduler classifies the failure as output loss due to timeout termination and generates the first type of output loss diagnostic information. The scheduler marks the current simulation task as a timeout failure, freezes the flow cursor corresponding to the current simulation task, releases the running resources occupied by the algorithm subprocess, and writes the first type of output loss diagnostic information into the project audit log. The main program is not blocked during this process, and other parallel simulation tasks continue to execute.

[0114] Scenario 3: The MATLAB / Simulink model wrapper plugin exits normally but does not generate the expected output file.

[0115] In one embodiment, the target plugin is a MATLAB / Simulink model wrapper plugin, applicable to the time-domain response analysis stage. After the scheduler generates a standard input JSON file and starts the algorithm subprocess, the algorithm subprocess calls the corresponding model wrapper program to execute the simulation. The algorithm subprocess exits normally with a process exit code indicating success, but due to an incorrect configuration of the model's internal output path, the output.mat, output.h5, or output.json files declared by the target plugin's metadata are not generated in the dedicated working directory.

[0116] In this embodiment, the scheduler performs an expected output file existence check after the algorithm subprocess terminates. Since the algorithm subprocess exited normally and the process exit code indicates success, but the expected output file does not exist, the scheduler does not consider the task a successful simulation. Instead, it categorizes the failure as a normal exit with missing output, generating a second type of output missing diagnostic information. This second type of output missing diagnostic information includes the task identifier, plugin unique identifier, execution stage identifier, process exit code, expected output file path, output file existence status, standard output log path, and failure classification identifier. The scheduler marks the current simulation task as an output missing failure, freezes the process cursor corresponding to the current simulation task, and prompts the plugin that it did not generate the expected output file according to the output contract. Simultaneously, it does not report non-existent output results to the process engine, thereby preventing subsequent analysis stages from continuing execution based on missing results.

[0117] Scenario 4: The output.json file exists, but the field types do not match the output JSONSchema.

[0118] In one embodiment, the target plugin is a Python script plugin or a C++ executable plugin, applicable to the balancing calculation stage, linearization analysis stage, or frequency domain response analysis stage. The algorithm subprocess exits normally and generates an output.json file in its dedicated working directory. However, some fields in this output.json file do not conform to the data structure declared in the output_schema field of the target plugin's metadata. For example, required fields are missing, numeric fields are written as strings, array dimensions are inconsistent with the output JSONSchema, or numeric fields exceed the preset range.

[0119] In this embodiment, after confirming the existence of the output.json file, the scheduler performs structural validation on the output.json file based on the output JSONSchema in the target plugin metadata. When the validation fails, the scheduler does not deserialize the output.json file into an internal data object, but instead generates output structure anomaly diagnostic information. This output structure anomaly diagnostic information includes the task identifier, plugin unique identifier, execution stage identifier, expected output file path, validation failure field path, expected data type, actual data type, validation failure reason, and failure category identifier. The scheduler marks the current simulation task as having failed validation, freezes the flow cursor corresponding to the current simulation task, and writes the output structure anomaly diagnostic information to the project audit log; simultaneously, the main program and other parallel simulation tasks continue to run.

[0120] As can be seen from the above fault injection embodiments, this application does not simply record whether the algorithm subprocess has successfully exited, but rather combines and judges the termination method of the algorithm subprocess, the process exit code, the existence status of the expected output file, the output structure verification result, and the standard output / standard error log to obtain a task failure diagnosis result that can distinguish the cause of the fault. Therefore, when a single heterogeneous algorithm plugin malfunctions, the flight control simulation platform can limit the anomaly to the current simulation task and retain diagnostic information for engineering traceability and problem localization.

[0121] While this application provides the method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in this embodiment is merely one possible execution order among many and does not represent the only execution order. In actual device or client product execution, the methods shown in this embodiment or the accompanying drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0122] like Figure 3 As shown in the illustration, this application also provides a flight control simulation scheduling device 300. The device includes: The processing module 301 is used to recursively scan the preset algorithm plugin directory, parse the metadata, and perform memory registration to obtain the memory capability registry.

[0123] The acquisition module 302 is used to acquire the execution stage information and context data of the current project, and to match the execution stage information with the memory capability registry to obtain the target plugin metadata.

[0124] The processing module 301 is also used to perform pre-verification and serialization processing on the context data and target plugin metadata to obtain a standard input file.

[0125] The processing module 301 is also used to integrate and process the target plugin metadata, standard input file and working directory path to obtain the algorithm subprocess.

[0126] The processing module 301 is also used to asynchronously monitor, manage timeouts, and record lifecycle data of the algorithm subprocess and target plugin metadata to obtain subprocess running diagnostic information.

[0127] The verification module 303 is used to perform existence checks, structure verification, result deserialization, and anomaly isolation on the algorithm subprocess, target plugin metadata, and subprocess running diagnostic information to obtain the simulation scheduling execution result.

[0128] Some modules in the apparatus described in this application can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0129] The apparatus or module described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. For ease of description, the above apparatus is described by dividing it into various modules according to their functions. When implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware. Of course, a module that implements a certain function can also be implemented by combining multiple sub-modules or sub-units.

[0130] The methods, apparatus, or modules described in this application can be implemented in a computer-readable program code manner. The controller can be implemented in any suitable manner, such as a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of a memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code manner, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included within it for implementing various functions can also be considered as structures within the hardware component. Alternatively, the device used to implement various functions can be viewed as either a software module that implements the method or a structure within a hardware component.

[0131] This application also provides an apparatus, the apparatus comprising: a processor; a memory for storing processor-executable instructions; wherein, when the processor executes the executable instructions, it implements the method described in this application.

[0132] This application also provides a non-volatile computer-readable storage medium storing a computer program or instructions thereon, which, when executed, enables the method described in this application embodiment to be implemented.

[0133] Furthermore, in the various embodiments of the present invention, each functional module can be integrated into a processing module, or each module can exist independently, or two or more modules can be integrated into a single module.

[0134] The aforementioned storage media include, but are not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Cache, Hard Disk Drive (HDD), or Memory Card. The memory can be used to store computer program instructions.

[0135] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, or it can be embodied in the process of data migration. The computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0136] The various embodiments described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. All or part of this application can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, mobile communication terminals, multiprocessor systems, microprocessor-based systems, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

[0137] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of this application.

Claims

1. A flight control simulation scheduling method, characterized in that, include: The preset algorithm plugin directory is recursively scanned, metadata parsed, and memory registration is performed to obtain the memory capability registry. Obtain the execution phase information and context data of the current project, and match the execution phase information with the memory capability registry to obtain the target plugin metadata; The context data and the target plugin metadata are pre-verified and serialized to obtain a standard input file; The target plugin metadata, the standard input file, and the working directory path are integrated and processed to create an algorithm subprocess. Asynchronous monitoring, timeout management, and lifecycle recording are performed on the metadata of the algorithm subprocess and the target plugin to obtain subprocess runtime diagnostic information. The existence check, structure verification, result deserialization, and anomaly isolation processes are performed on the algorithm subprocess, the target plugin metadata, and the subprocess runtime diagnostic information to obtain the simulation scheduling execution result.

2. The method of claim 1, wherein, The process of recursively scanning, parsing metadata, and registering memory in a preset algorithm plugin directory to obtain a memory capability registry includes: A recursive scan of the preset algorithm plugin directory is performed to obtain the plugin metadata file; The plugin metadata file is parsed to obtain plugin information, which includes a unique plugin identifier, applicable stage, execution command, input / output structure definition, timeout threshold, and version information. The plugin information is processed for memory storage to obtain an initial memory capacity registry. The initial memory capability registry is lazily loaded and refreshed to obtain the memory capability registry.

3. The method of claim 1, wherein, The process involves obtaining the execution phase information and context data of the current project, matching the execution phase information with the memory capability registry, and obtaining the target plugin metadata, including: The current project's running status is read and processed to obtain the current project's execution stage information; The working condition parameters, model file path, aerodynamic parameter file path, and user configuration parameters corresponding to the current project execution stage are integrated and processed to obtain project context data; The execution stage information of the current project is matched with the plugin applicable stage information in the memory capability registry to obtain a list of applicable algorithm plugins; The list of applicable algorithm plugins is automatically matched to obtain the target plugin; The registration information of the target plugin is extracted and processed to obtain the target plugin metadata.

4. The method of claim 1, wherein, The process of pre-validating and serializing the context data and the target plugin metadata to obtain a standard input file includes: The target plugin metadata is processed to extract the input structure, resulting in the input data structure definition. Perform a pre-structure verification process on the context data and the input data structure definition to obtain context data that passes the verification; The validated context data is subjected to structured serialization to obtain temporary text data; The temporary text data is written to a temporary file to obtain a temporary input file; The temporary input file is subjected to disk data synchronization processing to obtain a temporary input file with complete data; The temporary input file containing the complete data is atomically renamed to obtain the standard input file.

5. The method of claim 1, wherein, The process of integrating and creating a process from the target plugin metadata, the standard input file, and the working directory path to obtain an algorithm subprocess includes: The target plugin metadata is processed to extract execution commands, thereby obtaining the plugin execution commands; The process startup command is obtained by concatenating the command to be executed by the plugin, the absolute path of the standard input file, and the working directory path. The process startup instruction is adapted for cross-platform system calls to obtain the process creation interface call. The process creation interface call is executed to obtain an initial child process; The initial subprocess is isolated in an independent address space to obtain the algorithm subprocess.

6. The method according to claim 1, characterized in that, The asynchronous monitoring, timeout management, and lifecycle recording of the algorithm subprocess and the target plugin metadata to obtain subprocess runtime diagnostic information includes: The target plugin metadata is subjected to timeout threshold extraction processing to obtain the process timeout threshold; The startup time of the algorithm's subprocess is recorded to obtain the process startup timestamp; The process start timestamp and the process timeout threshold are configured to generate a process timeout timer. The running status of the algorithm's subprocesses is asynchronously polled to obtain the real-time status information of the subprocesses; The real-time status information of the subprocess is compared with the process timeout timer. If the runtime of the real-time status information of the subprocess exceeds the timing threshold of the process timeout timer, the algorithm subprocess is forcibly terminated and information is collected to obtain the basic running information of the subprocess. The basic runtime information of the subprocess is integrated with the process standard output and standard error stream log to obtain subprocess runtime diagnostic information.

7. A flight control simulation scheduling device, characterized in that, Applied to the method according to any one of claims 1 to 6, the apparatus comprises: The processing module is used to recursively scan the preset algorithm plugin directory, parse metadata, and perform memory registration to obtain the memory capability registry. The acquisition module is used to acquire the execution stage information and context data of the current project, and to match the execution stage information with the memory capability registry to obtain the target plugin metadata. The processing module is also used to perform pre-verification and serialization processing on the context data and the target plugin metadata to obtain a standard input file; The processing module is also used to integrate and process the target plugin metadata, the standard input file, and the working directory path to obtain an algorithm subprocess; The processing module is also used to asynchronously monitor, manage timeouts, and record lifecycle data of the algorithm subprocess and the target plugin metadata to obtain subprocess running diagnostic information; The verification module is used to perform existence checks, structure verification, result deserialization, and anomaly isolation on the algorithm subprocess, the target plugin metadata, and the subprocess runtime diagnostic information to obtain the simulation scheduling execution result.

8. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

Images