Software management module of on-satellite comprehensive processing system

Abstract

The invention discloses an on-satellite comprehensive processing system software management module, which is used for remotely managing software running on a satellite and realizing software uploading, software installation, software running, software unloading, software state monitoring and software exception recovery. The software management module comprises a serial port assembly, a software uploading and installing assembly and a software management assembly, and the serial port assembly receives external data through the FPGA, analyzes an uploading software package and provides the uploading software package for the software uploading and installing assembly; the software uploading and installing assembly is used for managing a storage path and an installing path of a software package and extracting key information and software installing functions of the uploading software package; the software management assembly is used for managing starting, stopping, unloading and running states after software installation and providing corresponding APIs for the outside. The software management module can realize an on-satellite APP management function, and can meet the management and control requirements of satellite service, control and the like and the requirement of on-satellite high-performance processing at the same time.

Description

Technical Field

[0001] The invention relates to the field of satellite integrated electronics, and in particular to a software management module for an integrated processing system on board a satellite. Background Art

[0002] In March 2019, Lockheed Martin unveiled SmartSat, a software-defined satellite technology architecture that it has been developing for many years. SmartSat is essentially a satellite-borne operating environment that can change the functions of satellites and assign new tasks through software "push" according to satellite mission requirements, just as convenient as adding an application (APP) to a smartphone, thereby changing the current situation that traditional satellites cannot change their capabilities after launch, and providing satellites with extremely strong elasticity and flexibility. In November 2018, the "Tianzhi-1" satellite, led by the Institute of Software of the Chinese Academy of Sciences, was successfully launched. The satellite has made initial progress in basic software-defined satellite technologies such as space-based high-performance computing platforms, satellite-borne operating environments, and satellite-borne APPs. The satellite-borne operating environment provides an application execution environment compatible with the mainstream computing environment on the ground to support the dynamic loading, execution, and scheduling of satellite-borne APPs. The satellite-borne APP can realize the scheduling and management of computing resources, storage resources, and exchange resources, and can also complete the preprocessing and intelligent information processing of payload data. It can also participate in satellite status information analysis and comprehensive processing of payload data.

[0003] The present invention proposes a software management module for the on-board processing system. By formulating standard APP development specifications, users can conveniently upload, delete, start and stop programs through the software management module of the on-board processing system, thereby realizing flexible control of user programs. At the same time, the module can also maintain and update the version information of the user program, ensuring that the system always runs the latest version, so as to improve the stability and security of the system. Summary of the invention

[0004] In view of the problems existing in the prior art, the purpose of the present invention is to provide an on-board integrated processing system software management module, which realizes the management function of the on-board APP by formulating standardized APP development specifications and a configurable remote control and telemetry protocol framework.

[0005] To achieve the above object, the present invention provides a software management module for an on-board integrated processing system, which is used to remotely manage the software running on the satellite, realize software uploading, software installation, software running, software uninstallation, software status monitoring and software abnormality recovery; the software management module comprises three parts: a serial port component, a software uploading and installation component, and a software management component, wherein The serial port component receives external data through FPGA, parses the upload software package and provides it to the software upload and installation component; The software registration and installation component is used to manage the storage path and installation path of the software package, extract key information of the registered software package and the software installation function; The software management component is used to manage the startup, stop, uninstallation, and running status of the software after installation, and provides a corresponding API interface to the outside.

[0006] Furthermore, the ground injects the software installation package into the onboard integrated processing system through the satellite-to-ground measurement and control link and the Beidou link, and then controls the installation, operation, stop, uninstallation and monitoring of the software through indirect instructions of the remote control and telemetry module.

[0007] Furthermore, the software management module defines the packaging format of the above-mentioned software packages. All software is packaged according to a unified directory structure, and the packaging format describes and defines the features of the software.

[0008] Furthermore, the feature definition includes: defining APPID, the installation path corresponds to APPID, and realizing centralized management of different software; secondly, defining the storage path and installation path after the software is annotated. After the annotation is completed, first unzip the description file in the installation package, extract the APPID therein, determine whether the APP has been installed and determine the installation directory; then rename the installation package to the file name containing APPID, so as to facilitate retrieval during installation. Furthermore, when installing the annotated software package, unzip it into a separate directory for each APP, and each APP does not affect each other; each APP can have its own configuration file, dynamic library and executable file.

[0009] Furthermore, each APP in the software management module includes its own configuration file, dynamic library, and executable file; when starting the software, the software management module first forks a child process, then adds the bin directory of the software package to the PATH environment variable of the child process, adds the lib directory to the LD_LIBRARY_PATH environment variable, and then executes the entry script or entry binary file specified in the app_info.ini file through the exec system call; the entry script can directly use the binary files in the bin directory of the software package and the dynamic libraries in the lib directory without setting the environment variables.

[0010] Furthermore, APP obtains the installation path of the current APP through the environment variable APP_INSTALL_PATH.

[0011] Furthermore, a multi-APP serial workflow is generated based on the installed APPs, so that the output of one APP is used as the input of the next APP, and multiple APPs are automatically run in series, so that process aggregation is supported between APPs.

[0012] Furthermore, the APPID of the process aggregation management and control software is set to n, where n is a positive integer. When APPn is executed, the execution process of APP aggregation is carried out in the order of runlist. After each APP is installed, an output directory is generated under its installation directory to store output items that may be generated by its execution. The output items are stored in the form of files, and their names are kept consistent.

[0013] Furthermore, when APPn is executed, as the parent process, all runlists are started as child processes; First, APP1 is started according to the start_cmd of APP1. APP1 obtains the input file in from input_path. After execution, the output result is stored in the out file in the output directory. The startup is still in the fork+execv mode. After obtaining the pid of the child process APP1, the waitpid function is used to block and monitor the status of the child process. When the status of the APP1 child process is terminated, the environment variable OUTPUT_PATH is set to the output directory path of APP1. Then, the out file in the output directory of APP1 is passed as input to APP2 for execution. The process is the same as before. The child process is started through ork+execv, and waitpid is blocked to wait for the process to terminate and return. After APP2 is executed, its output is saved in the output directory under the installation directory of APP2, and APP2 is stopped. Finally, reset the environment variable OUTPUT_PATH to the output directory path of APP2, start APP3, and store the output data in the directory of APP3 after execution. The subsequent process is similar until APPn.

[0014] The beneficial effects of the present invention are as follows: 1. The basic standards for on-board APP development are proposed. Users can develop on-board APP based on these standards, laying the foundation for the subsequent formation of an on-board APP development ecosystem.

[0015] 2. A usage model for aggregating multiple APP software processes on board a satellite is proposed. Multiple independent APPs can be started in a specific order through configuration files to achieve specific functions.

[0016] 3. A flexible remote control and telemetry data configuration framework has been designed, which can flexibly define remote control commands and telemetry parameters through JSON configuration files, realize on-demand configuration of remote control and telemetry data, and solve the problems of insufficient flexibility and difficulty in reuse caused by the customized development of basic functions such as telemetry and remote control of traditional on-board software. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It shows the design architecture diagram of the software management module of the on-board integrated processing system according to the present invention; Figure 2 It shows the architecture diagram of the telemetry and remote control module according to the present invention; Figure 3 It shows a hardware block diagram of the on-board integrated processing system based on microsystems and micromodules according to the present invention; Figure 4 A BeiDou link diagram according to the present invention is shown. DETAILED DESCRIPTION

[0018] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0019] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.

[0020] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0021] The following combination Figure 1-Figure 4 The specific embodiments of the present invention are described in detail. It should be understood that the specific embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0022] The on-board integrated processing system software management module proposed in the present invention can realize functions such as on-board satellite services, control, intelligent management and control, high-performance processing, Beidou short message communication, etc. Among them, the on-board integrated processing system includes an on-board data management and control module, an on-board data processing module and a Beidou short message communication module, wherein the on-board data management and control module is the management and control module of the entire satellite, and has the ability to run high-reliability software such as satellite services and control. The on-board data processing module is used to realize intelligent processing of optical and other remote sensing data, and has high-performance processing capabilities. The Beidou short message communication module is used to realize data communication through Beidou short messages.

[0023] When the on-board integrated processing system is in orbit, the software running on the satellite is remotely managed through the software management module to achieve functions such as software injection, software installation, software operation, software uninstallation, software status monitoring, and software abnormal recovery. The ground injects the software installation package into the on-board integrated processing system through the satellite-to-ground measurement and control link and the Beidou link, and then controls the installation, operation, stop, uninstallation, and monitoring of the software through indirect instructions.

[0024] According to the on-board integrated processing system software management module of the present invention, the packaging format of the registered software package is defined, and all software is packaged according to a unified directory structure, and the software is described and characterized in the packaging format. The APPID is mainly defined, and the installation path corresponds to the APPID to achieve centralized management of different software. Secondly, the storage path and installation path after the software is registered are defined. After the registration is completed, the APPID must be extracted first to distinguish whether the APP has been installed and determine the installation directory. Therefore, the description file in the installation package must be unzipped first, the APPID must be extracted, and then the installation package must be renamed to the file name containing the APPID, so as to facilitate retrieval during installation. In addition, it also has the functions of starting, stopping, and uninstalling the software. The software start, stop, and uninstall functions are realized through the indirect instruction function.

[0025] The design architecture diagram of the software management module of the on-board integrated processing system according to the present invention is as follows Figure 1 The software management module includes three parts: a serial port component, a software upload and installation component, and a software management component. The serial port component receives external data through FPGA, parses the upload software package and provides it to the software upload and installation component; the software upload and installation component manages the storage path and installation path of the software package, extracts the key information of the upload software package and the software installation function; the software management component is responsible for the software operation management functions such as starting, stopping, uninstalling, and running status after software installation, and provides corresponding API interfaces to the outside.

[0026] The specific implementation process of the on-board integrated processing system software management module according to the present invention is as follows: (1) APP packaging: When the software management module installs the above-mentioned software package, it will be decompressed into a separate directory for each APP, and each APP will not affect each other. Each APP has its own configuration file, dynamic library, and executable file.

[0027] The designed directory structure is as follows: The designed directory structure is as follows: / app_1app_info.ini / bin demo.sh random.img / data demo.txt / etc demo.cfg / lib / tmp demo.log Directory and file description: bin: stores executable files of software; etc: stores possible configuration files; lib: stores possible dynamic library files; Data: stores private data of the APP, which is maintained by the APP itself and still exists after power failure and restart. It can be cleared through remote control commands; tmp: Temporary storage directory, used by APP to temporarily store data. This directory will be cleared when the APP is restarted or the system is restarted; app_info.ini: APP description file, including APPID and the startup command of the APP.

[0028] When the software management module installs the above-mentioned software package, it will unzip it into a separate directory for each APP, and each APP will not affect each other. Each APP can have its own configuration file, dynamic library, and executable file. When the software management module starts the software, it first forks a child process, then adds the bin directory of the software package to the PATH environment variable of the child process, adds the lib directory to the LD_LIBRARY_PATH environment variable, and then executes the entry script or entry binary file specified in the app_info.ini file through the exec system call. The binary files in the bin directory of the software package and the dynamic libraries in the lib directory can be directly used in the entry script without setting the environment variables. The APP obtains the installation path of the current APP through the environment variable APP_INSTALL_PATH.

[0029] (2) APP upgrade package installation The designed directory structure is as follows: / app_1_update app_info.ini test1.txt test2.txt Directory and file description: app_info.ini: description file, mainly used to describe what type of package the package is; Others: Files to be upgraded.

[0030] (3) File encapsulation The designed directory structure is as follows: / file_upload app_info.ini file.txt Directory and file description: app_info.ini: description file, mainly used to describe what type of package the package is; Others: Files to be upgraded.

[0031] Unlike software upgrade packages, the upgrade path of software upgrade packages is limited to files with relative paths within the software directory, while file packages can be used to upgrade files with paths outside the software directory.

[0032] (4) Software Process Aggregation APPs support process aggregation, that is, a multi-APP serial workflow is generated based on the installed APPs. The software process aggregation function makes the output of one APP the input of the next APP, realizing the automatic serial operation of multiple APPs. To realize the process aggregation function, a new type of APP needs to be added as the process aggregation management software, and its software description file app_info.ini is as follows: [info] type = 4 funcid = 1 appid = 60 autostart = 0 version = 1.0.0 platform = 1 [runlist] app1:input_path:output_path1 app2:output_path1:output_path2 app3:output_path2:output_path3 The [runlist] field defines the complete aggregation process that needs to be executed. Each line represents an executed APP in order. Taking the first line "app1:input_path:output_path1" as an example, app1 means that the noted APP1 is executed first. Input_path represents its input item path. If it is empty, it means that no input item is required. Output_path1 represents its execution output item path. If it is empty, it means that no output is required.

[0033] The APPID of the process aggregation management and control software is set to 60. When APP60 is executed, the execution process of APP aggregation is carried out in the order of runlist. After each APP is installed, an output directory will be generated under its installation directory to store the output items that may be generated by its execution. The output items are stored in the form of files, and their names are kept consistent.

[0034] When APP60 is executed, as the parent process, all runlists, that is, APPs in the process, are started as child processes. First, according to the start_cmd of APP1, APP1 is started. APP1 obtains the input item file in from the input_path. After execution, the output result is stored in the out file in the output directory. The startup is still in the fork+execv mode. After obtaining the pid of the child process APP1, the waitpid function is used to block and the status of the child process is monitored. After the status of the APP1 child process is terminated, the environment variable OUTPUT_PATH is set to the output directory path of APP1. Then, the out file in the output directory of APP1 is passed as an input item to APP2 for execution. The process is consistent with the previous one. The child process is started by ork+execv, and waitpid is blocked to wait for the process to terminate and return. After APP2 is executed, its output is stored in the output directory under the installation directory of APP2, and APP2 is stopped. Finally, the environment variable OUTPUT_PATH is reset to the output directory path of APP2, and APP3 is started. After execution, the output data is stored in the directory of APP3. The subsequent processes are similar. In this way, the aggregate execution process of APP can be realized, and the execution result of the previous APP can be used as the input parameter of the next APP.

[0035] When the software in the aggregation process runs abnormally, the abnormal status of the corresponding APP is returned through the telemetry response, and an attempt is made to stop the APP using stop_cmd. If it cannot be stopped, kill is called to terminate the subprocess, and finally the process aggregation APP is stopped. After that, the ground or central computer can choose to restart the process aggregation APP or re-upload the ordinary APP with the abnormality according to the returned status information.

[0036] (5) Remote control commands and telemetry parameter configuration based on json files Remote control and telemetry mainly receive satellite and ground commands, and then parse them according to the predefined data format, analyze the meaning of the received data, and then perform corresponding operations. The designed telemetry and remote control module architecture is as follows Figure 4 As shown. The telemetry and remote control module contains five parts: CAN component, broadcast data component, remote control data block component, telemetry command component and indirect instruction component. The CAN component receives external data through FPGA and sends the data generated by other components to FPGA. The broadcast data component parses and processes various types of broadcast data, and calls the system time setting API to set the system time. The remote control data block component parses and processes various types of data block data. The telemetry command component parses the telemetry command, calls the system information acquisition API to read the system status information, organizes the telemetry data according to the telemetry parameters defined in the json file, sends it to FPGA through the CAN component, and provides the telemetry data control API to other modules. The indirect instruction component parses the indirect instruction and calls the corresponding processing function according to the indirect instruction content defined in the json file.

[0037] In terms of remote control instructions, the json configuration file can be uploaded to a fixed directory through the software upload module to complete the customization of indirect instructions. The json configuration contains the reception and judgment method of the indirect instruction protocol frame and the content of each defined indirect instruction. When the remote control and telemetry process is started, monitor whether the json file exists in the fixed directory of the file system. If it exists, the json file customization method is used to parse and process it. At the same time, the customer compiles the related functions of the indirect instruction, such as the receiving function of the indirect instruction, the definition of the instruction set and the corresponding processing function, the response function of the indirect instruction, etc. into a dynamic library, and uploads it to the intelligent integrated electronic stand-alone through the software management module. When executing, the remote control and telemetry module opens the specified dynamic library through dlopen and uses internal functions to process the indirect instruction.

[0038] In terms of telemetry, you can upload a json configuration file to a fixed directory through the software upload module to customize the fast / slow-changing telemetry. The json configuration contains the reception judgment method of the fast / slow-changing telemetry protocol frame and the defined response frame content. When the remote control telemetry process is started, monitor whether the json file exists in the fixed directory of the file system. If it exists, the json file customization method is used for parsing.

[0039] The hardware block diagram of the on-board integrated processing system of the present invention is as follows: Figure 3 As shown, it includes an on-board data control module, an on-board data processing module and a Beidou short message communication module.

[0040] Among them, the onboard data control module is the main control module of the satellite, which is completed with a high-performance SIP chip. SIP integrates high-performance CUP and FPGA modules, in which the CPU runs the core software system, and the FGPA module realizes the expansion and conversion of the CPU and external interfaces. The peripheral design memory, RS422, PPS, CAN bus, Ethernet, analog acquisition, configuration refresh circuit and other interfaces or circuits can realize UART communication, CAN bus communication, Ethernet communication and other functions to meet the needs of satellite services and control. Due to the limited capacity of the program memory integrated in SIP, it cannot support the operation of the Linux system. Two NAND FLASH are configured externally as program memory, with a single chip capacity of 16GB. Two NAND FLASH are mounted on SIP, and the same image files are stored in both, which are backed up for each other. After the single system startup fails, the backup can be switched to start. The system startup position is determined by external instructions and the Boot program. After the Boot detects that the main NAND FLASH fails to start, the startup position is automatically switched to the backup NAND FLASH. The FPGA inside the SIP has a total dose index of 100Krad. As an SRAM-type FPGA, there is still the possibility of single-particle upset, so a refresh configuration circuit is designed for it. For single-particle upset events, the reliability of the FPGA is improved by designing triple-module redundancy for key functions, implementing state machine security (to prevent deadlock), and verifying fault-tolerant design for data communication. The on-board data processing module is used to realize real-time on-orbit processing of optical and other payload data. It is based on a commercial-grade micro-module acceleration module (such as Atlas200 or NVIDIA TX2 and other products), and the peripheral design includes secondary power conversion circuits, EMMC storage circuits, Ethernet interface circuits, and other low-speed interface circuits. In order to improve reliability, the on-board data processing module adopts a dual design, namely on-board data processing module 1 and on-board data processing module 2. The two modules can work independently at the same time or be used as backups. The control signals for power-on control and reset control are generated by the control part.

[0041] The Beidou short message communication module is used to provide the system with a satellite-to-ground communication link. The Beidou short message communication module is connected to the satellite data control module through two RS422s, and the satellite data control module is connected to the satellite data processing module through the network port, RS422 and other interfaces to achieve a complete communication link, which is used to realize four functions, namely telemetry and control, shell interaction, software management, and data interaction.

[0042] The shell interaction function is a new type of satellite-ground interaction method pioneered by this system, that is, the interactive support of shell terminals, which supports most shell command line operations. The ground connects to the Beidou short message communication module on the satellite through the Beidou short message communication service system, and then connects to the control module through two serial ports. One serial port can be regarded as connecting to the debugging serial port of the control module, and the other serial port is connected by the control module to the debugging serial port of the processing module. The specific process of data transmission is: the ground encodes the shell command, and sends the encoded shell command to the Beidou short message communication module on the satellite through the Beidou short message communication service system. After receiving the command, the Beidou short message communication module forwards it to the control module. The control module determines whether it is a shell command of the control module or the processing module according to the coding protocol. If it is a shell command of the control module, it is executed directly. If it is a shell command of the processing module, it is forwarded to the processing module through the serial port for execution. The execution result is transmitted to the ground through the Beidou short message communication module. In this way, a system that controls and manages the control module or the processing module in a command line manner is realized, such as Figure 2 To ensure system security, two security strategies are designed: 1. Shell commands use double-frame encoding. A shell command is encoded as two identical A / B frames and sent simultaneously. The control module or processing module can only execute the command after receiving the A / B frames and confirming that the shell commands in the two frames are consistent, to prevent the execution of incorrect shell commands due to unstable wireless communication links. 2. Shield individual sensitive shell commands to prevent fatal failures caused by misoperation by ground personnel.

[0043] Compared with traditional telemetry and remote control interaction, shell interaction has the following advantages: 1. Not limited by the visible range of the ground control station, the onboard integrated processing system can be controlled and managed in real time 24 hours a day, 7 days a week; 2. Not restricted by remote control and telemetry, you can view the system background operation and modify the system configuration in real time.

[0044] The working modes of the onboard integrated processing system include main working mode and backup working mode. In the main working mode, as the brain of the satellite, it replaces the functions of the satellite service, control and other subsystems of the conventional satellite platform, manages and monitors the operating status of other subsystems of the satellite platform, controls the power on and off of each payload, receives data from various sensors, and outputs attitude and orbit control instructions to each actuator to ensure the safety of satellite operation. In the backup working mode, as a single satellite, it accepts the management of the satellite platform, mainly completes the payload data processing function, cooperates with the satellite platform's satellite service, control and other subsystems to complete the onboard data processing work, and provides sufficient computing power support for the satellite. The device enters the main working mode by default when it is powered on. When a special situation occurs in the satellite's operating status and it is not suitable to continue working in the main working mode, it will automatically or by ground control switch to the backup working mode.

[0045] Any process or method description in the flowchart of the present invention or described in other ways herein can be understood as a module, segment or part of a code including one or more executable instructions for implementing the steps of a specific logical function or process, which can be implemented in any computer-readable medium for use by an instruction execution system, device or equipment, and the computer-readable medium can be any medium containing storage, communication, propagation or transmission programs for use by execution systems, devices or equipment, including read-only memories, magnetic disks or optical disks, etc.

[0046] In the description of this specification, the description with reference to the terms "embodiment", "example", etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. In addition, those skilled in the art can combine or combine different embodiments or examples described in this specification and the features therein without causing any contradiction.

[0047] Although the above content has shown and described the embodiments of the present invention, it can be understood that the above embodiments are exemplary and cannot be understood as limitations of the present invention. Ordinary technicians in the field can change, modify, replace, modify and other update operations on the above embodiments within the scope of the present invention.

Claims

1. A software management module for an onboard integrated processing system, characterized in that: The software management module is used to remotely manage the software running on the satellite, realize software registration, software installation, software operation, software uninstallation, software status monitoring and software abnormal recovery; the software management module includes three parts: serial port component, software registration and installation component, and software management component. The serial port component receives external data through FPGA, parses the upload software package and provides it to the software upload and installation component; The software registration and installation component is used to manage the storage path and installation path of the software package, extract key information of the registered software package and the software installation function; The software management component is used to manage the startup, stop, uninstallation, and running status of the software after installation, and provides a corresponding API interface to the outside.

2. The on-board integrated processing system software management module according to claim 1, characterized in that: The ground injects the software installation package into the onboard integrated processing system through the satellite-to-ground measurement and control link and the Beidou link, and then controls the installation, operation, stop, uninstallation and monitoring of the software through indirect instructions of the remote control and telemetry module.

3. The on-board integrated processing system software management module according to claim 1, characterized in that: The software management module defines the packaging format of the above-mentioned software packages. All software is packaged according to a unified directory structure, and the packaging format describes and defines the features of the software.

4. The on-board integrated processing system software management module according to claim 3, characterized in that: The feature definition includes: defining APPID, the installation path corresponds to APPID, and realizing centralized management of different software; secondly, defining the storage path and installation path after the software is registered. After the registration is completed, first unzip the description file in the installation package, extract the APPID therein, determine whether the APP has been installed and determine the installation directory; then rename the installation package to the file name containing the APPID, so as to facilitate retrieval during installation.

5. The on-board integrated processing system software management module according to claim 4, characterized in that: When installing the above software package, unzip it into a separate directory for each APP, and each APP will not affect each other; each APP has its own configuration file, dynamic library and executable file.

6. The on-board integrated processing system software management module according to claim 4, characterized in that: Each APP in the software management module includes its own configuration file, dynamic library, and executable file. When starting the software, the software management module first creates a child process through the fork() function, then adds the bin directory of the software package to the PATH environment variable of the child process, adds the lib directory to the LD_LIBRARY_PATH environment variable, and then executes the entry script or entry binary file specified in the app_info.ini file through the exec system call. The entry script directly uses the binary files in the bin directory of the software package and the dynamic libraries in the lib directory, without setting the environment variables.

7. The on-board integrated processing system software management module according to claim 6, characterized in that: APP obtains the installation path of the current APP through the environment variable APP_INSTALL_PATH.

8. The on-board integrated processing system software management module according to claim 6, characterized in that: Generate a multi-APP serial workflow based on the installed APPs, so that the output of one APP is used as the input of the next APP, realize the automatic serial operation of multiple APPs, and support process aggregation between APPs.

9. The on-board integrated processing system software management module according to claim 8, characterized in that: The APPID of the process aggregation control software is set to n, where n is a positive integer. When APPn is executed, the execution process of APP aggregation is carried out in the order of runlist. After each APP is installed, an output directory is generated under its installation directory to store the output items generated by its execution. The output items are stored in the form of files, and their names are kept consistent.

10. The on-board integrated processing system software management module according to claim 9, characterized in that: When APPn is executed, it acts as a parent process and all runlists are started as child processes; First, APP1 is started according to the start_cmd of APP1. APP1 obtains the input file in from input_path. After execution, the output result is stored in the out file in the output directory. The startup is still in the fork+execv mode. After obtaining the pid of the child process APP1, the waitpid function is used to block and monitor the status of the child process. When the status of the APP1 child process is terminated, the environment variable OUTPUT_PATH is set to the output directory path of APP1. Then, the out file in the output directory of APP1 is passed as input to APP2 for execution. The process is the same as before. The child process is started through ork+execv, and waitpid is blocked to wait for the process to terminate and return. After APP2 is executed, its output is saved to the output directory under the APP2 installation directory, and APP2 is stopped; Finally, reset the environment variable OUTPUT_PATH to the output directory path of APP2, start APP3, and store the output data in the directory of APP3 after execution. The subsequent process is similar until APPn.

Images