A description list-based simulation application cross-platform hosting system and method

Abstract

The application discloses a simulation application cross-platform hosting system and method based on a description list, unifies a service list to describe a running contract of a simulation application, combines a cross-platform hosting execution flow, and designs a deployment configuration fusion weight calculation formula and a service hosting health degree evaluation formula to realize quantitative control, realizes standardized and quantitative deployment and running management of the simulation application under multiple nodes and multiple operating systems, effectively solves problems, such as great difficulty in hosting of various simulation applications in a simulation platform, high cross-platform adaptation cost, scattered operation and maintenance entrances, and one-sided operation and maintenance decision, and can be directly applied to application hosting of scenes, such as a military simulation platform, an edge simulation node and a deduction training system, and has remarkable industrial practicability and popularization value.

Description

Technical Field

[0001] This application belongs to the fields of distributed application hosting, edge node operation and maintenance, and cross-platform operation control technology, and particularly relates to a simulation application cross-platform hosting system and method based on a description list. Background Technology

[0002] In complex simulation platforms and edge node operation scenarios, the system typically includes multiple programs such as simulation engine, model service, scenario processing component, log collection tool and auxiliary task process. The operation mode of each program is significantly different, and there are problems such as inconsistent start / stop methods, chaotic log collection methods, vague start success standards, large differences in cross-platform adaptation, and inconsistent runtime configuration access.

[0003] Existing managed solutions are mainly divided into two categories: manual script-based managed solutions and lightweight managed solutions that only start processes. Manual script-based managed solutions have a low barrier to entry, but it is difficult to unify logs, probes, and status collection, and they have poor cross-platform reusability. Lightweight managed solutions only solve the program startup problem and do not describe the complete operation contract of the service. As a result, subsequent log management, health checks, restarts, and status reports still need to be customized separately for each service, which cannot meet the operation and maintenance needs of edge platforms that contain multiple simulation components.

[0004] Therefore, there is an urgent need for a unified service list hosting mechanism for simulation applications, which provides unified service description and hosting for simulation engines, model services, inference training components and edge simulation nodes. This mechanism is suitable for standardized deployment and operation management scenarios of different types of services in simulation platforms under multi-node and multi-operating system environments, enabling different types of simulation applications to access the platform in a unified description manner and achieve standardized deployment, startup, shutdown, log collection, readiness judgment and status reporting under various operating system environments. Summary of the Invention

[0005] This invention addresses the problems in existing simulation application hosting, such as inconsistent runtime contract descriptions, high cross-platform adaptation costs, inaccurate startup success judgments, and fragmented operation and maintenance entry points. It provides a simulation application cross-platform hosting system and method based on a description list. The system adopts a unified service list hosting mechanism, enabling different types of applications to access the platform with the same description. Agents then complete deployment, startup, shutdown, log collection, readiness judgment, and status reporting in various operating system environments according to a unified process, achieving standardized hosting of simulation applications across multiple nodes and operating systems.

[0006] To address the aforementioned technical problems, the first aspect of this invention discloses a cross-platform hosting system for simulation applications based on a description list. The system includes at least: a service list definition module, a list storage and parsing module, a deployment and integration module, a node hosting and execution module, and a node execution result processing module. The service list definition module, deployed at the central management terminal, is used to define the structured service list information of the simulation application's runtime contract and output the structured service list information to the list storage and parsing module. The structured service list information includes, but is not limited to, service name, version, startup entry point, startup parameters, stop entry point, stop parameters, environment variables, log mapping relationship, ready probe information, and applicable platform and service description. The list storage and parsing module is deployed at the central management terminal. It is used to read and parse the structured service list information during the packaging, deployment and node execution phases, and output the default parameters of the service list to the deployment fusion module. The deployment fusion module is deployed at the central management end and is used to fuse the default parameters with the system orchestration configuration, node attributes and runtime overriding parameters to obtain the final deployment context and send it to the node managed execution module. The node-hosted execution module is deployed on the target node and is used to create an instance directory, a persistent service list, and instance metadata on the target node based on the final deployment context, and to perform service start, stop, and restart operations according to the service list; the node-hosted execution module synchronizes the process start result, instance directory information, instance metadata, local service list, operation results, and process status to the node execution result processing module; The node execution result processing module is deployed on the target node and is used to receive and process the process startup result, instance directory information, instance metadata, local service list, operation result and process status sent by the node managed execution module, and obtain and display service running status data. The service list definition module, the list storage and parsing module, the deployment and integration module, the node hosting and execution module, and the node execution result processing module are connected in sequence.

[0007] As an optional implementation, in the first aspect of the present invention, the node execution result processing module includes: a log discovery and mapping unit, a readiness detection unit, a metadata recovery unit, and a status reporting unit; The log discovery and mapping unit is used to parse the physical log path according to the log logical name defined in the service list, manage the console output logs and custom business logs in a unified manner, and synchronize the log access results to the status reporting unit. The readiness detection unit is used to perform readiness detection according to the readiness probe type, target and timeout time defined in the service list after the service process is started, to determine whether the service is truly capable of providing services to the outside world, and to synchronize the probe results and detection time to the status reporting unit. The status reporting unit is used to report the running status, process PID, runtime, start / stop results and abnormal information of the service instance to the central management terminal for unified display and control. The metadata recovery unit is used to receive, process, and save the instance metadata and local service list sent by the node hosting execution module, so as to realize the rediscovery of the managed instances and the recovery of the hosting information after the central management terminal or the node execution terminal is restarted. The output of the node-hosted execution module is connected to the input of the log discovery and mapping unit, the input of the readiness detection unit, the input of the metadata recovery unit, and the input of the status reporting unit, respectively; the output of the log discovery and mapping unit and the output of the readiness detection unit are connected to the input of the status reporting unit, respectively.

[0008] A second aspect of this invention discloses a cross-platform hosting method for simulation applications based on a description list, the method comprising: S1, Based on the service list definition module, obtain structured service list information; S2, the central management terminal uses the list storage and parsing module and the deployment fusion module to process the structured service list information to obtain the target node deployment request information; S3, based on the target node deployment request information, the node execution terminal uses the node hosting execution module to create an instance directory and persist data, thereby obtaining instance directory data and local persistent data; The locally persistent data includes local deployment request information, local application file information, and local instance metadata; S4, the node execution end uses the node managed execution module to process the instance directory data, the local persistent data, and the structured service list information to obtain console log data; S5, the node execution end uses the node execution result processing module to process the console log data and the structured service list information to obtain and report service running status data.

[0009] As an optional implementation, in the second aspect of the present invention, the structured service list information is stored in the root directory of the simulation application service package and adopts a parseable structured format such as JSON, YAML, or TOML; the structured service list information includes at least the following fields: service name, service version, startup entry point, startup parameter array, stop entry point, stop parameter array, environment variable key-value pairs, log logical name-physical path mapping, ready probe type, ready probe target, ready probe timeout, applicable platform information, and service description.

[0010] As an optional implementation, in a second aspect of the present invention, the central management terminal utilizes the list storage and parsing module and the deployment fusion module to process the structured service list information to obtain target node deployment request information, including: S21, the central management terminal uses the list storage and parsing module to parse and process the structured service list information to obtain the corresponding version service list data; S22, the central management terminal uses the deployment fusion module to fuse the corresponding version service list data, system orchestration configuration, node attributes, and runtime overriding parameters to obtain the target node deployment request information.

[0011] As an optional implementation, in a second aspect of the present invention, the central management terminal utilizes the deployment fusion module to fuse the corresponding version service list data, system orchestration configuration, node attributes, and runtime override parameters to obtain target node deployment request information, including: The deployment fusion module performs parameter fusion according to the priority order of service list default values, system orchestration configuration, node attributes, and runtime overriding parameters. Based on the deployment configuration fusion weight calculation model, it performs orderly overriding of environment variable parameters and ready probe parameters to obtain the target node deployment request information. The expression for the deployment configuration fusion weight calculation model is: , , , , , in, : No. The final fusion weight of each deployment parameter; Configure the base weights of the sources in the service list by default; Configure the weights of the sources for system orchestration; Configure the source weight for node attributes; Configure the weight of the source for overriding parameters at runtime; For the first The configuration validity coefficient of each parameter in the service list; For the first The configuration validity coefficient of each parameter in the system orchestration configuration; For the first The validity coefficient of each parameter configuration in the node attributes.

[0012] As an optional implementation, in a second aspect of the present invention, the step of the node execution terminal creating an instance directory and persisting data using the node-hosted execution module based on the target node deployment request information, to obtain instance directory data and locally persisted data, includes: S31, the node execution end uses the node managed execution module to create a local instance directory on the target node and obtain instance directory data; S32, the node execution end uses the node hosting execution module to store the target node deployment request information in the local instance directory to obtain the local deployment request information; S33, the node execution end uses the node managed execution module to restore the application file to the local instance directory to obtain the local application file information; S34, the node execution end uses the node managed execution module to persistently save the instance metadata to the local instance directory, thereby obtaining the local instance metadata.

[0013] As an optional implementation, in a second aspect of the present invention, the node execution terminal utilizes the node-hosted execution module to process the instance directory data, the local persistent data, and the structured service list information to obtain console log data, including: S41, using the node-hosted execution module of the node execution terminal, the instance directory data is processed to obtain the target service list data; S42, using the node-hosted execution module of the node execution terminal, the target service list data is parsed and processed to obtain startup parameter data; S43, the node-managed execution module of the node execution end constructs startup command data based on the startup parameter data; S44, based on the startup command data, the node-managed execution module of the node execution end starts the service process and obtains standard process output information and standard error output information; S45, the standard process output information and the standard error output information are aggregated to obtain console log data.

[0014] As an optional implementation, in a second aspect of the present invention, the node execution terminal utilizes the node execution result processing module to process the console log data and the structured service list information to obtain and report service operation status data, including: S51, the node execution end uses the log discovery and mapping unit and the readiness detection unit of the node execution result processing module to process the console log data and the structured service list information to obtain service startup result data; S52, based on the control instructions of the central management terminal, the node execution terminal performs operations using the status reporting unit of the node hosting execution module and the node execution result processing module to obtain and report service operation status data.

[0015] As an optional implementation, in a second aspect of the present invention, the node execution end utilizes the log discovery and mapping unit and the readiness detection unit of the node execution result processing module to process the console log data and the structured service list information to obtain service startup result data, including: S511, the node execution end uses the log discovery and mapping unit of the node execution result processing module to process the console log data to obtain log mapping data; S512, based on the structured service list information, the node execution end uses the readiness detection unit of the node execution result processing module to perform readiness detection processing on the service, and obtains the actual detection time and detection result data; S513, determine whether the actual detection time is less than or equal to the preset ready probe timeout time, and obtain the detection time judgment result; When the detection time determination result is yes, the service starts successfully, the service startup flag is set to 1, and S514 is executed. When the detection time determination result is negative, the service startup fails, the service startup flag is set to 0, and S515 is executed. S514, Using the service hosting health assessment model, process the log mapping relationship table and the probe result data to obtain the service hosting health. The service startup identifier and the service hosting health status are fused together to obtain service startup result data; S515 terminates the newly started process / process tree, cleans up the running state, and reports the instance status as an error, obtaining startup failure status data; The service startup identifier and the startup failure status data are fused together to obtain service startup result data.

[0016] A third aspect of this invention discloses a cross-platform hosting device for simulation applications based on a description list, the device comprising: Memory containing executable program code; A processor coupled to the memory; The processor calls the program code stored in the memory to execute some or all of the steps in the cross-platform hosting method for simulation applications based on a description list disclosed in the second aspect of the present invention.

[0017] The fourth aspect of the present invention discloses a computer-readable storage medium, characterized in that the computer-readable storage medium stores computer instructions, which, when invoked, execute some or all of the steps in the cross-platform hosting method for simulation applications based on a description list disclosed in the second aspect of the present invention.

[0018] Compared with the prior art, the present invention has the following beneficial effects: First, it achieves a unified description of simulation application runtime contracts, incorporating all runtime-related information such as startup, shutdown, environment variables, log mapping, and readiness criteria into a unified structured service list. This solves the problem of scattered and inconsistent runtime contract descriptions in existing solutions and improves the standardization of simulation application hosting. Secondly, it reduces the cost of cross-platform adaptation. Through a unified service list structure and cross-platform entry point parsing, process control, and log takeover processes, the same set of managed logic can take effect on different operating systems such as Linux, Windows, and macOS, without the need to maintain managed logic separately for each platform. Third, it improves the accuracy of service startup success judgment by introducing a readiness probe mechanism, which uses the actual ability of the service to provide external services as the standard for successful startup, rather than just the existence of the process, thus avoiding the misjudgment of "the process has started but the service is not ready". It is especially suitable for applications with complex startup processes such as simulation engines and model loading programs. Fourth, it achieves unified management and access to logs, incorporating console logs and custom business logs into the same hosting framework. The platform accesses logs through a unified log logical name, shielding the differences in node file system paths and forming a unified log viewing entry point. Fifth, it enhances the synergy between deployment and operation. It achieves quantitative and orderly fusion of multi-source configurations through deployment configuration fusion weight calculation, taking into account both the standardization of simulation application hosting and the flexibility of on-site deployment. Moreover, the runtime overwrite results are written back to the local list, ensuring the consistency of the runtime contract after the instance restarts. Sixth, persistent recovery of service instances has been achieved. By persisting the service list and instance metadata to the instance directory, the managed instances can be rediscovered and the managed information restored after the node execution end restarts, which improves the platform's continuous operation and maintenance capabilities in edge node scenarios. Seventh, it has achieved quantitative assessment of service hosting status. By using the service hosting health assessment method, the hosting status is quantified from multiple dimensions, providing a quantitative basis for the platform's automatic operation and maintenance, improving the accuracy and efficiency of operation and maintenance decisions, and making it more suitable for the implementation of complex simulation systems. For multiple types of components such as model services, simulation engines, and simulation nodes, it can form a consistent operation and maintenance management method, reducing the overall operation and maintenance complexity of the military simulation platform. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram illustrating an application scenario of a cross-platform hosting device for simulation applications based on a description list, as disclosed in an embodiment of the present invention. Figure 2 This is a schematic diagram illustrating the composition of a cross-platform hosting system for simulation applications based on a description list, as disclosed in an embodiment of the present invention. Figure 3 This is a schematic diagram of the node execution result processing module of the simulation application cross-platform hosting method system based on a description list disclosed in an embodiment of the present invention; Figure 4 This is a schematic diagram of the cross-platform hosting method for simulation applications based on a description list disclosed in an embodiment of the present invention; Figure 5 This refers to the structured service list information of the cross-platform hosting method for simulation applications based on a description list disclosed in this embodiment of the invention; Figure 6 This is a schematic diagram of another cross-platform hosting device for simulation applications based on a description list, as disclosed in an embodiment of the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] It should be noted that, since the methods in this application are executed in computer devices, the processing objects of each computer device exist in the form of data or information; if time, quantity, location, etc. are mentioned in subsequent embodiments, they all refer to the existence of corresponding data so that the computer devices can process them.

[0025] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating a scenario in which the description-list-based cross-platform hosting device for simulation applications provided in this application is applied in a training simulation and inference system. The training simulation and inference system may include a computer device 100, which integrates the description-list-based cross-platform hosting device for simulation applications.

[0026] In this embodiment, the computer device 100 can be a standalone server, a server network or server cluster, or a cloud server. Those skilled in the art will understand that... Figure 1 The application environment given is merely an example and does not constitute a limitation on the application scenarios of the solution in this application.

[0027] In addition, such as Figure 1 As shown, the training simulation and deduction system may also include a memory 200 for storing description lists, structured service list data, default parameters and system orchestration configuration data.

[0028] This invention addresses the problems in existing simulation application hosting, such as inconsistent runtime contract descriptions, high cross-platform adaptation costs, inaccurate startup success judgments, and fragmented operation and maintenance entry points. It provides a simulation application cross-platform hosting system and method based on a description list. The system adopts a unified service list hosting mechanism, enabling different types of applications to access the platform with the same description. Then, the node execution agent completes deployment, startup, shutdown, log collection, readiness judgment, and status reporting in various operating system environments according to a unified process, achieving standardized hosting of simulation applications under multiple nodes and operating systems.

[0029] Example 1 Please see Figure 2 , Figure 2 This is a schematic diagram illustrating the composition of a cross-platform hosting system for simulation applications based on a description list, as disclosed in an embodiment of the present invention. Figure 2 The described cross-platform hosting system for simulation applications based on a description list is used in training simulation and deduction systems, such as local servers or cloud servers used for training simulation and deduction systems. This invention does not limit the scope of the application. Figure 2 As shown, this cross-platform hosting system for simulation applications based on a description list includes at least: Service list definition module 101, list storage and parsing module 102, deployment integration module 103, node hosting and execution module 104, and node execution result processing module 105; The service list definition module 101 is deployed at the central management terminal and is used to define the structured service list information of the simulation application operation contract, and output the structured service list information to the list storage and parsing module 102. The structured service list information includes, but is not limited to, service name, version, startup entry, startup parameters, stop entry, stop parameters, environment variables, log mapping relationship, ready probe information, and applicable platform and service description. The list storage and parsing module 102 is deployed at the central management terminal and is used to read and parse the structured service list information during the packaging, deployment and node execution stages, and output the default parameters of the service list to the deployment fusion module 103. The deployment fusion module 103 is deployed at the central management end and is used to fuse the default parameters with the system orchestration configuration, node attributes and runtime overriding parameters to obtain the final deployment context and send it to the node managed execution module 104. The node-hosted execution module 104 is deployed on the target node and is used to create an instance directory, a persistent service list, and instance metadata on the target node based on the final deployment context, and to perform service start, stop, and restart operations according to the service list; the node-hosted execution module synchronizes the process start result, instance directory information, instance metadata, local service list, operation result, and process status to the node execution result processing module 105. The node execution result processing module 105 is deployed on the target node and is used to receive and process the process startup result, instance directory information, instance metadata, local service list, operation result and process status sent by the node managed execution module 104, and obtain and display service running status data. The service list definition module 101, the list storage and parsing module 102, the deployment integration module 103, the node hosting execution module 104, and the node execution result processing module 105 are connected in sequence. As can be seen, the simulation application cross-platform hosting system based on the description list described in this embodiment of the invention, through the simulation application cross-platform hosting system composed of "service list definition module 101, list storage and parsing module 102, deployment fusion module 103, node hosting execution module 104 and the node execution result processing module 105", adopts a unified service list hosting mechanism, so that different types of applications can access the platform in the same description way. Then, the node execution agent completes deployment, startup, shutdown, log collection, readiness judgment and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0030] Optional, such as Figure 3 As shown, the node execution result processing module includes: a log discovery and mapping unit 1051, a readiness detection unit 1052, a metadata recovery unit 1053, and a status reporting unit 1054. The log discovery and mapping unit 1051 is used to parse the physical log path according to the log logical name defined in the service list, manage the console output logs and custom business logs in a unified manner, and synchronize the log access results to the status reporting unit 1054. The readiness detection unit 1052 is used to perform readiness detection according to the readiness probe type, target and timeout time defined in the service list after the service process is started, to determine whether the service is truly capable of providing services to the outside world, and to synchronize the probe results and detection time to the status reporting unit 1054. The metadata recovery unit 1053 is used to receive, process and save the instance metadata and local service list sent by the node hosting execution module 104, so as to realize the rediscovery of the managed instance and the recovery of the hosting information after the central management terminal or the node execution terminal is restarted. The status reporting unit 1054 is used to report the running status, process PID, runtime, start / stop results and abnormal information of the service instance to the central management terminal for unified display and control. The output of the node hosting execution module 104 is connected to the input of the log discovery and mapping unit 1051, the input of the ready detection unit 1052, the input of the metadata recovery unit 1053, and the input of the status reporting unit 1054, respectively; the output of the log discovery and mapping unit 1051 and the output of the ready detection unit 1052 are connected to the input of the status reporting unit 1054, respectively. It should be noted that the status reporting unit 1054 uniformly reports the instance status, health, and operation information to the central management terminal, completing the managed closed loop; As can be seen, the cross-platform hosting system for simulation applications based on description lists described in this embodiment of the invention, through the node execution result processing module composed of "log discovery and mapping unit 1051, readiness detection unit 1052, metadata recovery unit 1053 and readiness detection unit 1054", adopts a unified service list hosting mechanism, enabling different types of applications to access the platform in the same description way. Then, the node execution agent completes deployment, startup, shutdown, log collection, readiness judgment and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0031] Example 2 Please see Figure 4 , Figure 4 This is a flowchart illustrating a cross-platform hosting method for simulation applications based on a description list, as disclosed in an embodiment of the present invention. Figure 4 The described cross-platform hosting method for simulation applications based on description lists is applied to training simulation and inference systems, such as local servers or cloud servers used for training simulation and inference systems, and this embodiment of the invention is not limited thereto. Figure 4 As shown, this cross-platform hosting method for simulation applications based on a description list includes: S1, Based on the service list definition module, obtain structured service list information; It should be noted that the service list definition module generates a unified and structured service list information for the simulation application to be hosted; S2, the central management terminal uses the list storage and parsing module and the deployment fusion module to process the structured service list information to obtain the target node deployment request information; It should be noted that the central management terminal reads the service list of the corresponding version in the structured service list information through the list storage and parsing module, and then merges the default value of the service list with the system orchestration configuration, node attributes, and runtime overriding parameters through the deployment fusion module to form a final deployment context containing basic service information, final set of environment variables, ready probe parameters, dynamic configuration file content, target node information, and instance identifier, and generates a deployment request for the target node, thus obtaining the target node deployment request information; S3, based on the target node deployment request information, the node execution end uses the node hosting execution module to create an instance directory and persist data, thereby obtaining instance directory data and local persistent data; The locally persistent data includes local deployment request information, local application file information, and local instance metadata; S4, the node execution end uses the node managed execution module to process the instance directory data, the local persistent data, and the structured service list information to obtain console log data; S5, the node execution end uses the node execution result processing module to process the console log data and the structured service list information to obtain and report service running status data; As can be seen, the cross-platform hosting method for simulation applications based on description lists described in the embodiments of the present invention adopts a unified service list hosting mechanism, which enables different types of applications to access the platform in the same description way. Then, the node execution agent completes deployment, startup, shutdown, log collection, readiness judgment and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0032] Optionally, the structured service list information is stored in the root directory of the simulation application service package, using a JSON, YAML, or TOML parsable structured format; the structured service list information includes at least the following fields: service name, service version, startup entry point, startup parameter array, stop entry point, stop parameter array, environment variable key-value pairs, log logical name-physical path mapping, ready probe type, ready probe target, ready probe timeout, applicable platform information, and service description. It should be noted that, as Figure 5As shown, the structured service list information includes at least service identity information, operation control information, observable information, and applicable platform information, serving as a unified basis for describing the simulation application's operation contract. The structured service list information is stored in the root directory of the simulation application service package, using a parsable structured format such as JSON, YAML, or TOML, and includes at least the following fields: Name (service name), Version (service version), Entrypoint (startup entry point), Args (startup parameter array), StopEntrypoint (stop entry point), StopArgs (stop parameter array), Env (environment variable key-value pairs), LogPaths (log logic name-physical path mapping), ReadinessType (ready probe type), ReadinessTarget (ready probe target), ReadinessTimeout (ready probe timeout), OS (applicable platform information), and Description (service description). For example, for a simulation model service, the structured service list information can be defined as follows: the service name is the model service identifier; the entry point is bin / start-model; the parameters are the listening address, model directory, and instance number; the environment variables include the running mode and resource path; the log path includes console logs and business logs; and the ready probe uses HTTP health checks.

[0033] It should be noted that, in this way, the service packages submitted by different R&D personnel have a unified description boundary before entering the platform, avoiding the need to manually supplement the runtime information during subsequent deployment; As can be seen, the cross-platform hosting method for simulation applications based on description lists described in the embodiments of the present invention adopts a unified structured service list information to provide data support for different types of applications to access the platform in the same description way by utilizing a unified service list hosting mechanism. Then, the node execution agent completes deployment, startup, shutdown, log collection, readiness judgment and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0034] Optionally, the central management terminal uses the inventory storage and parsing module and the deployment fusion module to process the structured service inventory information to obtain target node deployment request information, including: S21, the central management terminal uses the list storage and parsing module to parse and process the structured service list information to obtain the corresponding version service list data; It should be noted that the parsing process refers to reading the data of the corresponding field according to the field type to obtain the corresponding version service list data; It should be noted that when the central management terminal Master initiates instance deployment, it parses and reads the default running parameters in the service list to obtain the corresponding version service list data; reads the module configuration for the service in the system orchestration layer to obtain the system orchestration configuration; and reads node attributes and runtime overriding parameters. The node attributes include node IP, hostname, and node ID; the runtime overriding items include ready probe parameters and environment variable increments. S22, the central management terminal uses the deployment fusion module to fuse the corresponding version service list data, system orchestration configuration, node attributes, and runtime override parameters to obtain the target node deployment request information; It should be noted that the central management terminal reads the service list of the corresponding version in the structured service list information through the list storage and parsing module, and then merges the default value of the service list with the system orchestration configuration, node attributes, and runtime overriding parameters through the deployment fusion module to form a final deployment context containing basic service information, final set of environment variables, ready probe parameters, dynamic configuration file content, target node information, and instance identifier, and generates a deployment request for the target node to obtain the target node deployment request information; It should be noted that the central management terminal first reads the default probes and default environment variables in the list, and then overlays the orchestration layer system orchestration configuration according to the predetermined priority to finally form the "running contract that is truly effective for this deployment". This can merge the "service package default value" and "site differential configuration" into the same set of managed semantics. When the central management terminal Master sends the final probe parameters to the node execution terminal Agent, the node execution terminal Agent can write back these runtime overwrite results to the local service.json, thereby ensuring that subsequent instance restarts can still use the real running contract determined during this deployment, instead of falling back to the initial default value in the package. As can be seen, in implementing the cross-platform hosting method for simulation applications based on description lists described in this embodiment of the invention, the central management terminal uses the list storage and parsing module and the deployment fusion module to process the structured service list information to obtain the target node deployment request information. This provides data support for using a unified service list hosting mechanism so that different types of applications can access the platform in the same description manner. Then, the node execution agent completes deployment, startup, shutdown, log collection, readiness judgment and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0035] Optionally, the central management terminal utilizes the deployment fusion module to fuse the corresponding version service list data, system orchestration configuration, node attributes, and runtime override parameters to obtain target node deployment request information, including: The deployment fusion module performs parameter fusion according to the priority order of service list default values, system orchestration configuration, node attributes, and runtime overriding parameters. Based on the deployment configuration fusion weight calculation model, it performs orderly overriding of environment variable parameters and ready probe parameters to obtain the target node deployment request information. It should be noted that the target node deployment request information includes service basic information, final set of environment variables, ready probe parameters, dynamic configuration file content, target node information, and instance identifier; It should be noted that after the central management terminal sends out the target node deployment request information, the node execution terminal writes the runtime overwrite result back to the locally persistent service.json, ensuring that the actual runtime contract of this deployment is used after the instance restarts; The expression for the deployment configuration fusion weight calculation model is: , , , , , in, : No. The final fusion weight of each deployment parameter; Configure the base weights of the sources in the service list by default; Configure the weights of the sources for system orchestration; Configure the source weight for node attributes; Configure the weight of the source for overriding parameters at runtime; For the first The configuration validity coefficient of each parameter in the service list; For the first The configuration validity coefficient of each parameter in the system orchestration configuration; For the first The validity coefficient of each parameter in the node attributes; For deployment parameter identification; It should be noted that the first... The final fusion weight of each deployment parameter is used to characterize the effective weight of that parameter in the final deployment context; the base weight of the default configuration source of the service manifest is the core configuration baseline weight, which is pre-configured by platform operations and maintenance personnel on the Master side; the weight of the system orchestration configuration source is the platform-level global configuration weight, which is pre-configured by platform operations and maintenance personnel on the Master side; the weight of the node attribute configuration source is the target node personalized configuration weight, which is pre-configured by platform operations and maintenance personnel on the Master side; the weight of the runtime override parameter configuration source is the temporary configuration weight for a single deployment, which is pre-configured by platform operations and maintenance personnel on the Master side; the first The configuration validity coefficient of each parameter in the service list is used to characterize whether the parameter is validly defined in the list. It is generated by the list storage and parsing module after parsing the service list. The coefficient is 1 if the parameter is defined and 0 if it is not defined. The configuration validity coefficient of each parameter in the system orchestration configuration represents whether the parameter is effectively defined at the orchestration layer. It is generated by the deployment and fusion module after reading the system orchestration configuration library; a value of 1 indicates a defined parameter, and 0 indicates an undefined parameter. The configuration validity coefficient of each parameter in the node attributes represents whether the parameter is effectively defined at the node level. It is generated by the deployment fusion module after collecting the target node attribute information. If the parameter is defined, it is 1; otherwise, it is 0. The deployment parameter identifier is a unique identifier for the deployment parameter, covering all fusionable deployment parameters such as environment variables, ready probe parameters, and log path parameters. It should be noted that the deployment configuration fusion weight calculation model described above achieves priority fusion of multi-source configurations. Through weight product and complement calculation, it strictly follows the coverage order of "service list default value, system orchestration configuration, node attributes and runtime overridden parameters" to avoid parameter conflicts. A configuration validity coefficient is introduced to weight the validly defined parameters in each configuration source, and undefined parameters are automatically skipped, improving the flexibility and adaptability of the fusion logic. The influence of each configuration source on the final deployment parameters is quantified, improving the accuracy and controllability of parameter fusion. It adapts to the differentiated configuration requirements of simulation applications across nodes and platforms, taking into account both standardized basic configurations and personalized on-site configurations. As can be seen, in implementing the cross-platform hosting method for simulation applications based on a description list as described in this embodiment of the invention, the deployment fusion module performs parameter fusion according to the priority order of service list default values ​​→ system orchestration configuration → node attributes → runtime overriding parameters. Based on the deployment configuration fusion weight calculation model, the environment variable parameters and ready probe parameters are systematically overridden to obtain the target node deployment request information. This provides data support for using a unified service list hosting mechanism so that different types of applications can access the platform in the same description way. Then, the node execution agent completes deployment, startup, shutdown, log collection, ready judgment, and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0036] Optionally, based on the target node deployment request information, the node execution terminal uses the node managed execution module to create an instance directory and persist data, obtaining instance directory data and locally persisted data, including: S31, the node execution end uses the node managed execution module to create a local instance directory on the target node and obtain instance directory data; It should be noted that the instance directory data adopts a hierarchical naming structure. The directory structure of a normal deployment instance is instances / {SystemID} / {ServiceName}_{InstanceID}, and the directory structure of an extended managed instance is instances / external / {SystemID} / {InstanceID}. S32, the node execution terminal uses the node hosting execution module to store the target node deployment request information in the local instance directory to obtain the local deployment request information; It should be noted that storing the target node deployment request information in the local instance directory means saving the target node deployment request information to the local instance directory with the name service.json. S33, the node execution end uses the node managed execution module to restore the application file to the local instance directory to obtain the local application file information; It should be noted that restoring the application files to the local instance directory means that the node execution end restores the application file package to the instance directory; S34, the node execution end uses the node managed execution module to persistently save the instance metadata to the local instance directory to obtain the local instance metadata; It should be noted that the instance metadata includes at least the instance identifier, system identifier, service name, version, instance directory path, and deployment time, which are used to rescan the instance directory, restore the instance identity, and the local path index after the node execution end restarts. It should be noted that, based on the target node deployment request information, the node execution end uses the node hosting execution module to create an instance directory and persist data, obtaining instance directory data and locally persisted data. That is, after receiving the target node deployment request information, the node execution end creates an independent instance directory on the target node through the node hosting execution module, restores the application files to the instance directory, and persistently saves the service list named service.json and instance metadata to the instance directory, while caching the instance directory path to the local index. As can be seen, the cross-platform hosting method for simulation applications based on description lists described in the embodiments of the present invention, based on the deployment request information of the target node, the node execution end uses the node hosting execution module to create an instance directory and persist data, obtaining instance directory data and local persistent data. This provides data support for using a unified service list hosting mechanism so that different types of applications can access the platform in the same description way. Then, the node execution end Agent completes deployment, startup, shutdown, log collection, readiness judgment and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0037] Optionally, the node execution end utilizes the node-hosted execution module to process the instance directory data, the local persistent data, and the structured service list information to obtain console log data, including: S41, using the node-hosted execution module of the node execution terminal, the instance directory data is processed to obtain the target service list data; It should be noted that the node execution end reads the service list in the instance directory through the node hosting execution module to obtain the target service list data; S42, using the node-hosted execution module of the node execution terminal, the target service list data is parsed and processed to obtain startup parameter data; It should be noted that the node execution end uses the node managed execution module to clean up old PID information and lock the instance directory; the parsing process means that the target service list data is parsed and the Entrypoint and Args are read according to the field identifier to obtain the startup entry, startup parameters and environment variables, and the startup parameter data is obtained. It should be noted that the node execution end follows cross-platform rules for parsing the startup entry point: if the startup entry point is an absolute path or contains path separators, the executableness of the corresponding file is checked directly; if the startup entry point is a relative path, the parsing is based on the instance directory; if the startup entry point has no path information, it first searches in the current working directory, and if not found, it searches in the system PATH; in Windows environment, the .exe extension is automatically completed, and in Linux / macOS environment, executable permissions are automatically checked and completed. S43, the node-managed execution module of the node execution end constructs startup command data based on the startup parameter data; It should be noted that the startup command data was obtained; S44, based on the startup command data, the node-managed execution module of the node execution end starts the service process and obtains standard process output information and standard error output information; It should be noted that, when the instance directory or an external working directory is used as the process working directory, the node-managed execution module of the node execution end starts the service process, which means that the service process is started with the instance directory or a specified external working directory as the process working directory. It should be noted that if the startup is successful, the node execution agent will write the PID to the PID file in the instance directory and include the process in subsequent monitoring. When stopping, if a StopEntrypoint is defined in the manifest, the graceful stop script will be executed first; if not defined, it will degenerate into a general stop method, such as signal or process tree termination. This allows the platform to adapt to simulation engines with graceful exit capabilities as well as ordinary components that only support general termination. The current implementation also supports a two-level strategy of "prioritizing the execution of custom stop scripts and reverting to general process tree cleanup after timeout". This can take into account some simulation engines that need graceful resource unloading and also prevent instances from being in an uncontrollable state for a long time when the stop script fails. S45, the standard process output information and the standard error output information are aggregated to obtain console log data; It should be noted that the process of aggregating the standard process output information and the standard error output information to obtain console log data means that the standard output and standard error output of the process are aggregated into a unified console log file under the instance directory to obtain the console log data. It should be noted that the node execution agent, by default, redirects the stdout and stderr of the managed process to app.log in the instance directory and exposes it as a unified "console log" to the platform. The LogPaths in the service manifest can also define other business logs, including but not limited to: EngineLog->logs / engine.log, TraceLog->logs / trace.log, and AccessLog->logs / access.log. When the platform requests logs, the node execution agent first finds the corresponding instance directory based on the instance ID, then reads the manifest to parse the mapping from the log logical name to the physical path. If the mapping is a relative path, it is concatenated based on the instance directory; if it is an absolute path, it can be accessed directly. In this way, the platform frontend sees a unified log logical name, rather than fragmented file system paths. Optionally, the log list itself can also be cached for a short time on the node execution agent side to reduce the overhead of repeatedly reading the disk when frequently clicking the front-end log drop-down box, which can support frequent operation and maintenance access in actual operation. As can be seen, in implementing the cross-platform hosting method for simulation applications based on description lists described in this embodiment of the invention, the node execution end uses the node hosting execution module to process the instance directory data, the local persistent data, and the structured service list information to obtain console log data. By using a unified service list hosting mechanism, different types of applications can access the platform to provide data support in the same description manner. Then, the node execution end Agent completes deployment, startup, shutdown, log collection, readiness judgment, and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0038] Optionally, the node execution end utilizes the node execution result processing module to process the console log data and the structured service list information to obtain and report service running status data, including: S51, the node execution end uses the log discovery and mapping unit and the readiness detection unit of the node execution result processing module to process the console log data and the structured service list information to obtain service startup result data; S52, based on the control instructions of the central management terminal, the node execution terminal uses the status reporting unit of the node hosting execution module and the node execution result processing module to perform operations, obtain and report service operation status data; As can be seen, by implementing the cross-platform hosting method for simulation applications based on description lists described in this embodiment of the invention, the node execution end uses the node execution result processing module to process the console log data and the structured service list information to obtain and report service operation status data. This achieves a unified service list hosting mechanism, enabling different types of applications to access the platform and provide data support in the same description manner. Then, the node execution end Agent completes deployment, startup, shutdown, log collection, readiness judgment, and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0039] Optionally, the node execution end utilizes the log discovery and mapping unit and the readiness detection unit of the node execution result processing module to process the console log data and the structured service list information to obtain service startup result data, including: S511, the node execution end uses the log discovery and mapping unit of the node execution result processing module to process the console log data to obtain log mapping data; It should be noted that the aforementioned processing means parsing the logical name and physical path mapping relationship of the custom business log based on the LogPaths field. The relative path is concatenated based on the instance directory, and the absolute path is accessed directly. The platform accesses the log through the log logical name and does not directly expose the node file system path. S512, based on the structured service list information, the node execution end uses the readiness detection unit of the node execution result processing module to perform readiness detection processing on the service, and obtains the actual detection time and detection result data; It should be noted that the node execution agent does not immediately recognize successful deployment after the process is started. Instead, it waits for the service to be ready according to the probe configuration in the list, including: TCP mode to check whether the port is reachable; HTTP mode to check whether the health check interface returns a normal status; TIME mode to wait for a fixed time; and NONE mode to indicate that the process can be considered successful as soon as it starts. It should be noted that if the probe fails, the system will not simply return a startup failure flag, but will actively terminate the newly started process and reclaim the relevant state to avoid leaving a semi-managed instance on the node execution end that has been "determined to have failed by the platform, but the process is still running in the background". S513, determine whether the actual detection time is less than or equal to the preset ready probe timeout time, and obtain the detection time judgment result; When the detection time determination result is yes, the service starts successfully, the service startup flag is set to 1, and S514 is executed. When the detection time determination result is negative, the service startup fails, the service startup flag is set to 0, and S515 is executed. S514, Using the service hosting health assessment model, process the log mapping relationship table and the probe result data to obtain the service hosting health. The service startup identifier and the service hosting health status are fused together to obtain service startup result data; It should be noted that the fusion process refers to combining the service startup identifier and the service hosting health status. S515 terminates the newly started process / process tree, cleans up the running state, and reports the instance status as an error, obtaining startup failure status data; If the probe fails within the specified timeout period, the node execution agent will perform the following actions: terminate the currently started process or process tree; clean up the relevant running status; report the instance status as an error; and allow subsequent restarts or deployments. The service startup identifier and the startup failure status data are fused together to obtain service startup result data; It should be noted that the fusion process refers to combining the service startup identifier and the startup failure status data. It should be noted that the node execution end uses the log discovery and mapping unit and the readiness detection unit of the node execution result processing module to process the console log data and the structured service list information to obtain service startup result data. The standard output and standard error output of the process are redirected to the unified console log file under the instance directory by default. The logical name and physical path mapping relationship of the custom business log are parsed according to the LogPaths field. The relative path is concatenated based on the instance directory, and the absolute path is accessed directly. The platform side accesses the log through the log logical name and does not directly expose the node file system path. As can be seen, in implementing the cross-platform hosting method for simulation applications based on description lists described in this embodiment of the invention, the node execution end uses the log discovery and mapping unit and the readiness detection unit of the node execution result processing module to process the console log data and the structured service list information to obtain service startup result data. This provides data support for using a unified service list hosting mechanism so that different types of applications can access the platform in the same description way. Then, the node execution end Agent provides data support for completing deployment, startup, shutdown, log collection, readiness judgment and status reporting in various operating system environments according to a unified process, thereby realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0040] Optionally, the expression for the service hosting health assessment model is: , , in, The managed health of the service instance; For probe health status; Connect health scores to logs; Assign a score to the process for running health; To configure and activate the health score; Weighting coefficients for the health dimension of ready probes; Add health dimension weighting coefficients to the logs; Weighting coefficients for the process health dimension; Configure and apply the weighting coefficients for the health dimension; Penalty factor for detection time; The actual time required for a ready probe; The timeout period for the ready probe; It should be noted that the managed health H of the service instance has a value range of [value missing]. A higher value indicates a healthier hosting status. It is in normal hosting status. In a state of alert, This is an abnormal state; the ready probe health score is generated by the ready detection unit based on the detection results. A successful detection on the first attempt is worth 100, and after multiple attempts, the score is calculated based on the pass rate. A failed detection is worth 0. This score characterizes the degree of service readiness and has a value range of [range missing]. The log access health score, generated by the log discovery and mapping unit, is 100 for all successfully accessed log entries, calculated based on the access rate for partial access, and 0 for no access. It represents the degree of completion of unified log access, with a value range of [range missing]. The process health score, generated by the node-hosted execution module, represents the survival and operational stability of the service process. A score of 100 indicates a process that is alive and without abnormal resource usage; a score calculated based on the severity of the abnormality indicates a process that is exiting; and a score of 0 indicates a process that has exited. The score ranges from [value range missing in original text]. The configuration effectiveness health score is jointly generated by the deployment fusion module and the node hosting execution module. A score of 100 represents all configurations successfully taking effect; partial effectiveness is calculated based on efficiency; and a score of 0 represents configuration failure. This score characterizes the actual effectiveness of the deployment configuration after fusion, and its value range is [range missing]. ; The platform pre-configures the ready detection time penalty coefficient according to the simulation application type; The basic parameters for health assessment are configured by platform operations and maintenance personnel; the actual ready detection time is generated in real time by the ready detection unit; the ready probe timeout time is generated by the list storage and parsing module from the service list. It needs to be explained that, , , , Highlight the core weights of the ready probe; It is adapted to the real-time requirements of simulation applications; , This meets the ready detection time requirements for simulation applications; It should be noted that the service hosting health assessment model described above comprehensively quantifies the managed operation status of service instances from multiple dimensions, providing a quantitative basis for platform-side operation and maintenance decisions. It overcomes the limitations of existing hosting solutions that rely solely on process liveness to determine service health. By employing a weighted assessment across four core dimensions—readiness probes, log access, process execution, and configuration activation—and introducing a penalty for readiness probe latency, it achieves quantitative quantification of service hosting status, accurately reflecting the actual operational capabilities of the service. This provides a clear quantitative basis for platform-wide automated operation and maintenance (such as early warnings, restarts, and alerts), improving the accuracy and automation level of operation and maintenance decisions. Furthermore, it adapts to the weight configuration requirements of different types of simulation applications, and can be adjusted... It adapts to the core hosting needs of different applications such as simulation engines and model services, and adapts to the operation and maintenance needs of complex simulation applications; health data can be reported to the Master through the status reporting module, realizing the unified display and sorting of the health status of multiple instance hosting, which makes it easier for the platform to focus on the operation and maintenance of abnormal instances; As can be seen, the cross-platform hosting method for simulation applications based on the description list described in the embodiments of the present invention adopts the service hosting health assessment model to comprehensively quantify the hosting operation status of service instances, providing a quantitative basis for platform-side operation and maintenance decisions, and realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0041] Optionally, based on the control commands from the central management terminal, the node execution terminal utilizes the status reporting unit of the node managed execution module and the node execution result processing module to perform operations, obtain and report service operation status data, including: S521, the central management terminal sends a control command to the node execution terminal; S522, Based on the control command, the node execution terminal uses the node managed execution module to perform the corresponding operation and obtain service running status data; It should be noted that when the node execution agent performs the corresponding operation, it does not assume that all services are started with absolute paths. Instead, it processes them in the following priority order: if the entry point already has a path separator or is an absolute path, it directly checks the corresponding file; if the entry point does not have a path, it first searches in the current working directory; if it is still not found, it searches for the executable file in the system PATH; in the Windows environment, it can automatically complete .exe; in the Linux or macOS environment, it can complete executable permissions; through this processing logic, the same manifest structure can work on multiple platforms without having to design a separate hosting model for each platform. S523, the node execution end uses the status reporting unit to report the service operation status data to the central management end; It should be noted that when the central management terminal issues control commands such as stop and restart to the node execution terminal, the node execution terminal performs the corresponding operation according to the service list through the node hosting execution module, and reports the real-time running status, PID, operation execution result and abnormal information of the service instance to the central management terminal through the status reporting unit of the node execution result processing module, so as to realize the status control of the entire service life cycle; As can be seen, the cross-platform hosting method for simulation applications based on description lists described in this embodiment of the invention, based on the control instructions of the central management terminal, the node execution terminal performs operations using the status reporting unit of the node hosting execution module and the node execution result processing module to obtain and report service operation status data. By using a unified service list hosting mechanism, different types of applications can access the platform to provide data support in the same description manner. Then, the node execution terminal Agent completes deployment, startup, shutdown, log collection, readiness judgment and status reporting in various operating system environments according to a unified process, realizing standardized hosting of simulation applications under multiple nodes and multiple operating systems.

[0042] Example 3 This embodiment is an application of the simulation application cross-platform hosting method based on description manifest described in Embodiment 2 to the unified hosting of simulation engine services, specifically as follows: A training and simulation system needs to deploy the same simulation engine service on different execution nodes. The service package generated for this service includes bin / engine, conf / engine.yaml, logs / , and service.json. The core configuration of service.json is as follows: Name: sim-engine; Version: V1.0.0; Entrypoint: bin / engine; Args: ["--port=19001", "--scene=. / scenes"]; ReadinessType: tcp; ReadinessTarget: :19001; ReadinessTimeout: 30 (unit: seconds); LogPaths: {"EngineLog":"logs / engine.log"}.

[0043] The central management Master is pre-configured with fusion weight parameters: , , , Service hosting health assessment parameters: , , , , When deploying the service, the central management Master injects differentiated environment variables and configuration files based on the attributes of different node execution ends. The node execution Agent executes a unified managed process on each node: it creates the instance directory instances / SYS001 / sim-engine_001 locally, restores the service package files to this directory, persists service.json and instance metadata, and writes it to the final configuration file; it parses the startup entry bin / engine, constructs the startup command with the instance directory as the working directory, injects environment variables, starts the simulation engine process, and redirects the process stdout / stderr to app.log in the instance directory; it executes the TCP ready probe, and the actual probe time is recorded. Within seconds, port 19001 was successfully connected. All logs were successfully integrated. The process runs normally. All configurations are now effective. Calculate the health of the managed property , Successful startup is determined; the instance PID, running status, managed health (98.33), and absence of abnormal information are reported to the Master; the platform accesses app.log through "Console Log" and logs / engine.log through "EngineLog" to achieve unified log viewing; the simulation engine service of each node execution end is managed through the above unified process, and the Master side realizes the status monitoring and health ranking of all node instances through a unified entry point. Even if the same simulation engine is deployed to different nodes, it can be managed with the same managed semantics.

[0044] Example 4 This embodiment is an application of the simulation application cross-platform hosting method based on description list described in Embodiment 2 to the cross-platform hosting of model services, specifically as follows: A certain model service needs to run on both Linux and Windows nodes. The service manifest generated for it defines only core unified information, including: service name and version, startup entry point in relative path form, startup parameter array, and HTTP readiness probe. Specifically, the service name is model-service, the version is V2.1.0, the startup entry point is bin / start-model, the startup parameters are config=. / conf / model.json, ReadinessType is http, ReadinessTarget is health, ReadinessTimeout is 20 (unit: seconds), and LogPaths is {"BusinessLog":"logs / business.log"}. The central management console (Master) configures unified fusion weights and health assessment parameters for this model service, specifically targeting the runtime environment variable parameter (…). This parameter is not defined in the service manifest. ), No definition in system orchestration ( ), Valid definitions in node attributes ( The runtime override parameter has no valid definition, and the calculation is as follows: This parameter takes the weight configured in the node attributes as its core effective weight. The node execution agent performs managed operations on Linux and Windows nodes respectively: Linux node: It parses the startup entry bin / start-model, uses the instance directory as the base to parse the path, completes the executable permissions, starts the process, and executes the HTTP ready probe to detect the / health interface. The actual detection time is... The detection passed within seconds, and the managed health level was calculated. The startup was determined to be successful. For Windows nodes: when parsing the startup entry point bin / start-model, the path is parsed based on the instance directory, and the .exe extension is automatically completed to bin / start-model.exe. After the process starts, the same HTTP ready probe detection is performed. The actual detection time is... The detection passed within seconds, and the managed health level was calculated. The startup was determined to be successful.

[0045] For the central management Master, the model services on Linux and Windows nodes are the same managed object. The management process, status reporting, and health assessment methods are completely unified. There is no need to adapt access logic separately for different platforms, avoiding the platform layer from maintaining two sets of application access logic for different operating systems. The managed health of both nodes is within the normal range, and the platform side does not need to perform any early warning processing.

[0046] Example 5 This embodiment describes the application of the cross-platform hosting method for simulation applications based on description lists, as described in Embodiment 2, in the hosting recovery after the Agent on the node execution end restarts. Specifically: Multiple model services and simulation engine instances are hosted on an edge node execution end. Due to a system upgrade, the Agent process restarted. After restarting, the Agent performed the following operations to restore the hosting: It scanned all local instance directories (instances / ), read the instance metadata and persistent service.json files in each directory, and restored the deployment configuration fusion weights and health assessment parameters for each instance; it restored the mapping relationship between instance identity, system identifier, and directory path based on the metadata, and re-cached the directory paths to the local index; it verified the process status of each instance, read the PID file and checked if the process was alive, and re-executed the ready probe detection and log access verification. The system recalculates the service hosting health of each instance and reports the verified instance status, hosting health, and any abnormal information to the central management Master. It restores log mapping relationships and ready probe configurations, allowing the platform to continue viewing logs and controlling the start / stop of each instance through a unified entry point. Abnormal instances with a health level below 50 are automatically restarted. Through the persistent service list and metadata in the instance directory, the node execution agent achieves seamless recovery of hosted instances. Furthermore, by recalculating the hosting health, it quickly identifies abnormal instances, ensuring the continuity and stability of the edge node hosting service and improving the platform's continuous operation and maintenance capabilities in the field environment.

[0047] It should be noted that the service manifest must use the filename service.json, but can be replaced with other structured description files; the manifest serialization format must be JSON, but can be replaced with YAML, TOML, or other parsable formats; ready probes must be limited to tcp, http, time, and none, but can be extended to script probes or other mechanisms; log collection must be completed through file path mapping, but can be extended to named pipes, system logs, or other log access methods; deployment overriding must be completed through the current orchestration structure, but can also be provided by other orchestration models; the parameters of the deployment configuration fusion weight calculation formula and the service hosting health assessment formula can be flexibly adjusted according to the platform operation and maintenance needs and the type of simulation application; a unified service manifest is used to describe the simulation application's runtime contract, and the node execution agent executes the hosting uniformly on different platforms according to the manifest, achieving orderly fusion of deployment configurations and comprehensive evaluation of hosting status through quantitative formulas.

[0048] Example 6 Please see Figure 6 , Figure 6 This is a schematic diagram of another cross-platform hosting device for simulation applications based on a description list, as disclosed in an embodiment of the present invention. Figure 6 The described apparatus can be applied to training simulation and deduction systems, such as local servers or cloud servers used for training simulation and deduction systems, and the embodiments of the present invention are not limited thereto. Figure 6 As shown, the device may include: Memory 201 storing executable program code; Processor 202 coupled to memory 201; The processor 202 calls the executable program code stored in the memory 201 to perform the steps in the cross-platform hosting method for simulation applications based on the description manifest described in Embodiment 2.

[0049] Example 4 This invention discloses a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform the steps in the cross-platform hosting method for simulation applications based on a description list described in Embodiment 2.

[0050] Example 7 This invention discloses a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to perform the steps in the description manifest-based cross-platform hosting method for simulation applications described in Embodiment 2.

[0051] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0052] It should be noted that all calculation expressions or mathematical functions in the embodiments of the present invention have undergone dimensionless processing of the variables involved before calculation.

[0053] It should be noted that in all the calculation expressions or mathematical functions in the embodiments of the present invention, the values ​​of the input independent variables all meet the reasonable requirements of the input value range of the calculation expression or mathematical function, and can ensure that the calculation expression or mathematical function can be calculated smoothly without violating physical laws or mathematical rules.

[0054] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), once programmable read-only memory (OTPROM), electronically erasable rewritable read-only memory (EEPROM), read-only optical disc (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0055] Finally, it should be noted that the cross-platform hosting system and method for simulation applications based on a description list disclosed in the embodiments of the present invention are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not to limit it. Although the present invention 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 of the technical features therein; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-platform hosting method for simulation applications based on a description list, characterized in that, A cross-platform hosting system for simulation applications based on a description list is provided, the system comprising at least: a service list definition module, a list storage and parsing module, a deployment and integration module, a node hosting and execution module, and a node execution result processing module; The service list definition module, deployed at the central management terminal, is used to define the structured service list information of the simulation application's runtime contract and output the structured service list information to the list storage and parsing module. The structured service list information includes, but is not limited to, service name, version, startup entry point, startup parameters, stop entry point, stop parameters, environment variables, log mapping relationship, ready probe information, and applicable platform and service description. The list storage and parsing module is deployed at the central management terminal. It is used to read and parse the structured service list information during the packaging, deployment and node execution phases, and output the default parameters of the service list to the deployment fusion module. The deployment fusion module is deployed at the central management end and is used to fuse the default parameters with the system orchestration configuration, node attributes and runtime overriding parameters to obtain the final deployment context and send it to the node managed execution module. The node-hosted execution module is deployed on the target node and is used to create an instance directory, a persistent service list, and instance metadata on the target node based on the final deployment context, and to perform service start, stop, and restart operations according to the service list; the node-hosted execution module synchronizes the process start result, instance directory information, instance metadata, local service list, operation results, and process status to the node execution result processing module; The node execution result processing module is deployed on the target node and is used to receive and process the process startup result, instance directory information, instance metadata, local service list, operation result and process status sent by the node managed execution module, and obtain and display service running status data. The service list definition module, the list storage and parsing module, the deployment and integration module, the node hosting and execution module, and the node execution result processing module are connected in sequence. The node execution result processing module includes: a log discovery and mapping unit, a readiness detection unit, a metadata recovery unit, and a status reporting unit. The log discovery and mapping unit is used to parse the physical log path according to the log logical name defined in the service list, manage the console output logs and custom business logs in a unified manner, and synchronize the log access results to the status reporting unit. The readiness detection unit is used to perform readiness detection according to the readiness probe type, target and timeout time defined in the service list after the service process is started, to determine whether the service is truly capable of providing services to the outside world, and to synchronize the probe results and detection time to the status reporting unit. The metadata recovery unit is used to receive, process, and save the instance metadata and local service list sent by the node hosting execution module, so as to realize the rediscovery of the managed instances and the recovery of the hosting information after the central management terminal or the node execution terminal is restarted. The status reporting unit is used to report the running status, process PID, runtime, start / stop results and abnormal information of the service instance to the central management terminal for unified display and control. The output of the node-hosted execution module is connected to the input of the log discovery and mapping unit, the input of the readiness detection unit, the input of the metadata recovery unit, and the input of the status reporting unit, respectively; the output of the log discovery and mapping unit and the output of the readiness detection unit are connected to the input of the status reporting unit, respectively. The method includes: S1, Based on the service list definition module, obtain structured service list information; S2, the central management terminal uses the list storage and parsing module and the deployment fusion module to process the structured service list information to obtain the target node deployment request information; S3, based on the target node deployment request information, the node execution end uses the node hosting execution module to create an instance directory and persist data, thereby obtaining instance directory data and local persistent data; The locally persistent data includes local deployment request information, local application file information, and local instance metadata; S4, the node execution end uses the node managed execution module to process the instance directory data, the local persistent data, and the structured service list information to obtain console log data; S5, the node execution end uses the node execution result processing module to process the console log data and the structured service list information to obtain and report service running status data; The central management terminal utilizes the list storage and parsing module and the deployment fusion module to process the structured service list information to obtain target node deployment request information, including: S21, the central management terminal uses the list storage and parsing module to parse and process the structured service list information to obtain the corresponding version service list data; S22, the central management terminal uses the deployment fusion module to fuse the corresponding version service list data, system orchestration configuration, node attributes, and runtime overriding parameters to obtain the target node deployment request information; The central management terminal utilizes the deployment fusion module to fuse the corresponding version service list data, system orchestration configuration, node attributes, and runtime override parameters to obtain target node deployment request information, including: The deployment fusion module performs parameter fusion according to the priority order of service list default values, system orchestration configuration, node attributes, and runtime overriding parameters. Based on the deployment configuration fusion weight calculation model, it performs orderly overriding of environment variable parameters and ready probe parameters to obtain the target node deployment request information. The expression for the deployment configuration fusion weight calculation model is: ， ， ， ， ， in, : No. The final fusion weight of each deployment parameter; Configure the base weights of the sources in the service list by default; Configure the weights of the sources for system orchestration; Configure the source weight for node attributes; Configure the source weights for overriding parameters at runtime; For the first The configuration validity coefficient of each parameter in the service list; For the first The configuration validity coefficient of each parameter in the system orchestration configuration; For the first The validity coefficient of each parameter in the node attributes; The node execution end utilizes the node execution result processing module to process the console log data and the structured service list information to obtain and report service operation status data, including: S51, the node execution end uses the log discovery and mapping unit and the readiness detection unit of the node execution result processing module to process the console log data and the structured service list information to obtain service startup result data; S52, based on the control instructions of the central management terminal, the node execution terminal uses the status reporting unit of the node hosting execution module and the node execution result processing module to perform operations, obtain and report service operation status data; The node execution end utilizes the log discovery and mapping unit and the readiness detection unit of the node execution result processing module to process the console log data and the structured service list information to obtain service startup result data, including: S511, the node execution end uses the log discovery and mapping unit of the node execution result processing module to process the console log data to obtain log mapping data; S512, based on the structured service list information, the node execution end uses the readiness detection unit of the node execution result processing module to perform readiness detection processing on the service, and obtains the actual detection time and detection result data; S513, determine whether the actual detection time is less than or equal to the preset ready probe timeout time, and obtain the detection time judgment result; When the detection time determination result is yes, the service starts successfully, the service startup flag is set to 1, and S514 is executed. When the detection time determination result is negative, the service startup fails, the service startup flag is set to 0, and S515 is executed. S514, Using the service hosting health assessment model, process the log mapping relationship table and the probe result data to obtain the service hosting health. The service startup identifier and the service hosting health status are fused together to obtain service startup result data; S515 terminates the newly started process / process tree, cleans up the running state, and reports the instance status as an error, obtaining startup failure status data; The service startup identifier and the startup failure status data are fused together to obtain service startup result data; The expression for the service hosting health assessment model is as follows: ， ， in, The managed health of the service instance; For probe health status; Connect health scores to logs; Assign a score to the process for running health; To configure and activate the health score; Weighting coefficients for the health dimension of ready probes; Add health dimension weighting coefficients to the logs; Weighting coefficients for the process health dimension; Configure and apply the weighting coefficients for the health dimension; Penalty factor for detection time; The actual time required for a ready probe; The timeout period for the ready probe.

2. The cross-platform hosting method for simulation applications based on a description list as described in claim 1, characterized in that, The structured service list information is stored in the root directory of the simulation application service package and uses a parsable structured format such as JSON, YAML, or TOML. The structured service list information includes at least the following fields: service name, service version, startup entry point, startup parameter array, stop entry point, stop parameter array, environment variable key-value pairs, log logical name-physical path mapping, ready probe type, ready probe target, ready probe timeout, applicable platform information, and service description.

3. The cross-platform hosting method for simulation applications based on a description list as described in claim 1, characterized in that, Based on the target node deployment request information, the node execution end uses the node managed execution module to create an instance directory and persist data, obtaining instance directory data and locally persisted data, including: S31, the node execution end uses the node managed execution module to create a local instance directory on the target node and obtain instance directory data; S32, the node execution terminal uses the node hosting execution module to store the target node deployment request information in the local instance directory to obtain the local deployment request information; S33, the node execution end uses the node managed execution module to restore the application file to the local instance directory to obtain the local application file information; S34, the node execution end uses the node managed execution module to persistently save the instance metadata to the local instance directory, thereby obtaining the local instance metadata.

4. The cross-platform hosting method for simulation applications based on a description list as described in claim 1, characterized in that, The node execution end uses the node-hosted execution module to process the instance directory data, the local persistent data, and the structured service list information to obtain console log data, including: S41, using the node-hosted execution module of the node execution terminal, the instance directory data is processed to obtain the target service list data; S42, using the node-hosted execution module of the node execution terminal, the target service list data is parsed and processed to obtain startup parameter data; S43, the node-managed execution module of the node execution end constructs startup command data based on the startup parameter data; S44, based on the startup command data, the node-managed execution module of the node execution end starts the service process and obtains standard process output information and standard error output information; S45, the standard process output information and the standard error output information are aggregated to obtain console log data.

Images