A missile-borne computer program dynamic loading system

Abstract

The application relates to a missile-borne computer program dynamic loading system and belongs to the technical field of missile-borne software loading. The method can solve the problems of insufficient adaptation of a traditional architecture, complicated program loading mode, low efficiency, high cost and the like. The method can give the missile-borne software self-adaptive capability through secondary guidance cooperation and a self-adaptive decision technology. The program dynamic loading can be realized by modifying the self-adaptive configuration through a missile-ground interface under the whole missile condition, and the program online dynamic loading can be realized by adapting the protocol during the operation of the missile-borne program. Therefore, the missile-borne system can maintain high operation flexibility in a complex and changeable environment.

Description

Technical Field

[0001] This invention relates to the field of software loading technology, and in particular to a dynamic loading system for missile-borne computer programs. Background Technology

[0002] Against the backdrop of rapid development in precision equipment systems, the requirements for low cost, low power consumption, high integration, independent controllability, and high performance are increasing. In terms of hardware architecture, traditional DSP / CPU+FPGA architectures and imported SOC architectures are increasingly unable to meet the comprehensive demands of current precision equipment systems for low cost, low power consumption, high integration, independent controllability, and high performance. In practical applications, their inadequacy in adaptability is becoming increasingly apparent, failing to support the efficient and stable operation of related systems. Regarding software loading and system adaptability, as the application scenarios of precision equipment continue to expand, higher demands are being placed on the equipment's ability to adapt to different scenarios. Taking missile-borne systems as an example, next-generation missile-borne systems need to have the ability to quickly adapt to and switch functions in real time according to the situation on the ground. As the core component of the missile-borne system, the missile-borne computer needs to cope with constantly changing target characteristics and complex scenarios. However, existing missile-borne software loading technology is difficult to support the realization of this core requirement. A prominent drawback is that dynamic program loading can only be achieved by modifying the hardware pin configuration. However, in the actual application environment after the missile is assembled, this modification method has extremely poor operability. If the hardware configuration needs to be modified, the entire missile must be disassembled. This process not only incurs high costs for disassembly, reassembly, and testing, but also consumes a lot of time, resulting in extremely low program loading efficiency, which seriously affects the maintenance efficiency and emergency response capability of the missile-borne system. It is evident that existing technologies have significant deficiencies in terms of hardware architecture adaptability, software loading flexibility, and efficiency. These deficiencies have become technical problems that urgently need to be solved. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a dynamic loading system for onboard computer programs, applied to the FMQL platform. By adopting a layered development model, the onboard system software is divided into a boot software layer and an application software layer. Through the collaborative cooperation and adaptive decision-making mechanism between the two layers, dynamic loading of the onboard computer program is achieved. This ensures dynamic loading of the onboard computer program based on the FMQL platform without disassembling the product and during program execution. This solves problems such as insufficient adaptability of traditional architectures, cumbersome program loading methods, low efficiency, and high costs, thus meeting the core requirements of current precision equipment systems for autonomy, controllability, high performance, high flexibility, and high efficiency.

[0004] In a first aspect, embodiments of the present invention provide a dynamic loading system for missile-borne computer programs. The system includes a boot software layer and an application software layer. Through the collaborative cooperation and adaptive decision-making mechanism between the two layers, dynamic loading of missile-borne computer programs is achieved.

[0005] The boot software layer includes primary boot and secondary boot, which are used to complete hardware initialization, system kernel loading, upper-layer application loading and management, general hardware resource reallocation, application software selection and execution, and online dynamic loading control of programs after the system is powered on.

[0006] The application software layer is used to carry the dedicated control logic for different specific application scenarios. It includes multiple differentiated versions of control software, each of which has complete task execution, hardware adaptation and status feedback capabilities, and can realize the functions of a specified application scenario under secondary guidance control.

[0007] In some embodiments of the present invention, the primary bootloader is the underlying basic bootloader module of the dynamic loading architecture of the onboard computer program, which is used to implement the configuration of core hardware resources and the loading of the system kernel.

[0008] In some embodiments of the present invention, the core hardware resource configuration is used to perform basic configuration of the key hardware of the missile-borne computer, eliminate the initial uncertainty after the hardware is powered on, and ensure that the hardware has basic working conditions.

[0009] The system kernel loading is used to load the core kernel program of the missile system into the runtime environment, providing underlying runtime support for the secondary boot and application software layers.

[0010] In some embodiments of the present invention, the secondary bootloader is the core control layer of the dynamic loading architecture of the missile-borne computer program; the operating environment of the secondary bootloader is the FMQL20S400 processor core 0 of the missile-borne computer. The secondary bootloader exclusively uses the computing resources of the FMQL20S400 core 0 throughout the process and does not share the kernel with the application software layer, so as to avoid interruption of decision-making or loading process due to software running conflicts; after the primary bootloader jumps to start, the secondary bootloader is always in the running state. Even if the application software layer switches versions or experiences a brief failure, its core decision-making and listening functions are not interrupted, ensuring real-time response to external commands.

[0011] In some embodiments of the present invention, the secondary boot includes a general hardware resource configuration module and an adaptive decision module, which work together to realize the functions of upper-layer application loading, dynamic resource allocation and online dynamic program loading.

[0012] In some embodiments of the present invention, the general hardware resource configuration module is used to realize the dynamic allocation, status monitoring and conflict coordination of general hardware resources according to the instructions of the adaptive decision module, so as to provide an adapted operating environment for different version control software of the application software layer.

[0013] In some embodiments of the present invention, the adaptive decision-making module realizes the selection, loading, and switching decisions of the control software by parsing external instructions, reading configuration files, and combining system status, and issues resource allocation instructions to the general hardware resource configuration module.

[0014] In some embodiments of the present invention, the adaptive decision-making module includes an adaptive configuration file submodule and an external decision-making protocol submodule.

[0015] In some embodiments of the present invention, the adaptive configuration file submodule is a functional unit for storing, managing, and accessing the core configuration data of the missile system. The data is stored in the configuration area of ​​the Flash storage chip in the form of a structured binary file and serves as the basic data source and status record carrier for adaptive decision-making.

[0016] The external decision-making protocol submodule is a standardized interface unit for the adaptive decision-making module to interact with external devices, defining the rules for the entire process of sending, receiving, verifying, and parsing instructions.

[0017] In some embodiments of the present invention, updating the adaptive configuration file includes the following steps:

[0018] After receiving the initialization completion and system kernel ready signals sent by the first-level bootloader, the adaptive configuration file update process is initiated.

[0019] Send a query command through the external bus interface and start a waiting timer;

[0020] Receive external data and perform integrity and validity checks;

[0021] After the query waiting timer expires, the system determines whether to accept a legitimate control software switching command based on the verification result of the external decision protocol submodule. If a legitimate control software switching command is received, the system updates the adaptive configuration file and locates the target software based on the new configuration. If no command is received or the command verification fails, the system directly reads the currently effective adaptive configuration file and locates the target software based on the default configuration.

[0022] The target control software is moved from the corresponding partition of Flash to DDR memory via the internal storage bus. After data integrity verification is completed, a startup command is sent to FMQL20S400 core 1 via the inter-core communication bus to trigger the software to run.

[0023] During the operation of the target software, the adaptive decision module continuously listens for external commands through the external bus interface while monitoring the software's operating status. When a new and valid switching command is received, a stop command is immediately sent through the inter-core communication bus. After the resources are released, the adaptive configuration file update is triggered again, realizing online dynamic switching of the software version.

[0024] This invention provides a dynamic loading system for missile-borne computer programs. The technical solutions provided by the embodiments of this invention bring at least the following beneficial effects:

[0025] (1) Significantly improve the flexibility and response speed of the missile-borne system in specific application scenarios. Through the solid design of multi-version differentiated control software, combined with the dynamic loading capability of secondary guidance, it can realize the rapid switching of specific application scenario tasks without disassembling the product or restarting the system, and adapt to the specific application scenario requirements of air-to-air, air-to-ground and other scenarios.

[0026] (2) Enhance system integration and lightweighting. Relying on the single-processor advantage of the FMQL platform and the layered modular design of the application software layer and the boot software layer, avoid the waste of resources in traditional multi-processor systems. Combined with a dynamic resource allocation mechanism, the system size, weight and power consumption are significantly reduced, meeting the core requirements of high integration and lightweighting of missile systems.

[0027] (3) Reduce development and maintenance costs and coupling. Each version of the application software layer is compiled independently and partitioned and solidified, decoupled from the boot software layer. Later upgrades only require adding or updating the corresponding BIN file, without changing the underlying boot logic, thus shortening the development cycle and reducing maintenance costs.

[0028] (4) Improve the reliability and security of system operation. Through configuration file primary and backup backup, multiple verification of software data, and automatic switching to backup version in case of failure, the system failure rate is reduced in harsh specific environments. At the same time, the access control and encryption mechanism prevents illegal tampering and ensures the security of specific application scenarios.

[0029] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0031] Figure 1This is a technical architecture diagram of a program dynamic loading system provided in an embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram illustrating the configuration file update process provided in an embodiment of the present invention. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0034] Before describing the technical solution of the present invention in detail, the technical background and technical terms involved in the technical solution will be explained first:

[0035] FMQL (Fudan Micro Qing Long): A series of domestically developed heterogeneous system-on-a-chip (SoC) chips launched by a Chinese university. These chips are commonly used as core components in electronic systems such as communication equipment, data acquisition, and radar signal processing. Their functionality is similar to the imported Xilinx ZYNQ platform, making them a crucial chip solution for ensuring hardware self-sufficiency in related fields. This series of chips is a completely domestically produced SoC product and is currently being used to build domestic experimental platforms for electronic information engineering courses in universities, as well as in equipment in industrial fields such as aerospace electronics. Its promotion and application help reduce the dependence of domestic electronic systems on imported heterogeneous SoC chips, providing hardware support for technological self-sufficiency in related fields.

[0036] This invention adopts a layered design, dividing the missile-borne system software into a guidance software layer and an application software layer. Through the cooperation between the two layers and an adaptive decision-making mechanism, the dynamic loading of the missile-borne computer program is realized. Figure 1 This is a schematic diagram of the technical architecture of the loading system provided in an embodiment of the present invention.

[0037] The bootloader layer is responsible for completing hardware initialization, system kernel loading, upper-layer application loading and management, general hardware resource reallocation, application software selection and execution, and online dynamic loading control of programs after system power-on. The bootloader layer includes primary boot and secondary boot, which will be described below.

[0038] The primary bootloader, as the underlying foundational bootloader module of the missile's onboard computer program dynamic loading architecture, is designed to ensure the readiness of the system's basic operating environment, providing the most fundamental operational support for the entire missile system. Specifically, it undertakes two core functions:

[0039] Core hardware resource configuration: Perform basic configuration of key hardware for the missile-borne computer to eliminate initial uncertainties after power-on and ensure that the hardware has basic working conditions;

[0040] System kernel loading: Loads the core kernel program of the missile system into the runtime environment, providing underlying runtime support for upper-layer software (secondary boot, application software layer) and ensuring the availability of the most basic system services.

[0041] The hardware initialization of the first-level boot focuses on the basic configuration of core hardware, without involving complex hardware function debugging. It only configures the key hardware parameters that ensure system startup, such as:

[0042] CPU clock configuration: Based on the hardware specifications of the FMQL platform processor (such as FMQL20S400), set key parameters such as CPU core clock frequency and peripheral interface clock frequency to ensure that the CPU and associated peripherals operate stably at the preset frequency and avoid hardware malfunctions due to clock instability.

[0043] External bus interface configuration: Configure basic parameters such as communication protocol type, baud rate, data frame format, and interface enable status for the external communication bus (such as SPI, CAN, Ethernet, etc.) of the missile computer to establish a basic communication link between external devices and the missile computer, and provide hardware communication guarantee for receiving external query commands and switching commands in the subsequent secondary guidance.

[0044] The first-level bootloader is designed and implemented in the following way:

[0045] Programming language selection: A mixed programming mode of assembly language and C language is adopted. Assembly language is used to write low-level code that directly manipulates hardware registers (such as clock register configuration and bus interface initialization instructions) to ensure the accuracy and efficiency of hardware operations; C language is used to encapsulate and call some initialization logic to improve code readability and maintainability.

[0046] Code Source and Adaptation Rules: The primary boot code is a base version provided by the FMQL platform processor chip manufacturer. This version has undergone rigorous hardware compatibility testing by the manufacturer to ensure compatibility with the processor core and onboard hardware platform. Developers do not need to modify the functionality or structure of the code (to avoid compromising the stability of the underlying boot logic). They can only modify simple configuration items such as clock frequency and bus communication parameters according to the specific needs of the onboard model to achieve rapid adaptation to different application scenarios.

[0047] After the first-level boot process is completed, the internal control bus sends a boot signal and hardware initialization and kernel loading status data (including CPU clock configuration parameters, external bus interface configuration results, kernel running status identifiers, etc.) to the second-level boot process to ensure that the second-level boot process starts based on the ready hardware and kernel environment.

[0048] The secondary bootloader, as the core control layer of the dynamic loading architecture of the missile-borne computer program, is a crucial hub connecting the primary bootloader and the application software layer. Its design revolves around "adaptive decision-making + dynamic loading control." This invention's secondary bootloader overcomes the limitations of traditional single-loading secondary bootloaders, endowing the missile-borne system software with dynamic adjustment capabilities. Specifically, the secondary bootloader receives the initialization results from the primary bootloader and initiates subsequent processes based on a stable hardware and kernel environment, providing a loading foundation for the application software layer. The secondary bootloader analyzes external instructions and system status through an adaptive mechanism, achieving precise selection of control software and dynamic allocation of hardware resources. The secondary bootloader runs continuously throughout the entire process, responding to external instructions in real time, completing the entire process management of loading, switching, and stopping the control software, ensuring the timeliness and reliability of dynamic program loading.

[0049] The secondary boot process operates on the FMQL20S400 processor core 0 of the onboard computer. The secondary boot process (including the adaptive decision-making module) exclusively uses the computing resources of the FMQL20S400 core 0 throughout the entire process and does not share the kernel with the application software layer, so as to avoid interruption of decision-making or loading processes due to software running conflicts. After the primary boot jumps to start, the secondary boot process is always running. Even if the application software layer switches versions or experiences a brief failure, its core decision-making and monitoring functions are not interrupted, ensuring real-time response to external commands.

[0050] like Figure 1 The secondary bootloader shown comprises two core modules: a general hardware resource configuration module and an adaptive decision-making module. These two modules work together to implement upper-layer application loading, dynamic resource allocation, and online dynamic program loading. The adaptive decision-making module is the core component of the secondary bootloader, responsible for intelligent decision-making and dynamic control. These will be described in detail below.

[0051] The general hardware resource configuration module is the resource scheduling hub of the secondary boot process. It is used to dynamically allocate, monitor the status and coordinate conflicts of general hardware resources according to the instructions of the adaptive decision module, and provide an adapted operating environment for different version control software of the application software layer.

[0052] The resource allocation function allocates core hardware resources of the FMQL20S400 processor according to software requirements. For example, CPU core 1 computing resources are allocated based on the core ratio and thread priority to ensure that high-priority application-specific task software has sufficient computing power; DDR storage resources are allocated to dedicated storage areas (running address, storage capacity) to avoid address conflicts between different software versions; external bus resources are allocated to the communication bandwidth and interrupt priority of buses such as SPI, CAN, and Ethernet to ensure the stability of communication between software and external devices; peripheral interface resources are enabled / disabled for the onboard computer's sensor interfaces, actuator interfaces, and other peripherals to adapt to the differentiated hardware peripheral requirements of different software.

[0053] The resource status monitoring function collects real-time hardware resource usage data, including the computing load of core 1, DDR storage utilization, bus communication traffic, and peripheral interface connection status, providing a basis for resource availability for the adaptive decision-making module.

[0054] The resource conflict coordination function triggers resource release and reallocation logic when a new software loading request conflicts with the current resource usage (such as address overlap or insufficient bandwidth). It prioritizes the core resource needs of the new software while ensuring the safe release of resources from the old software.

[0055] The adaptive decision-making module is the core of the secondary boot process. It parses external commands, reads configuration files, and considers system status to make decisions regarding the selection, loading, and switching of control software, and issues resource allocation commands to the general hardware resource configuration module. The adaptive decision-making module consists of two main sub-components: the adaptive configuration file sub-module and the external decision-making protocol sub-module. These will be described in detail below:

[0056] (1) Adaptive configuration file submodule

[0057] The adaptive configuration file submodule is a functional unit that stores, manages, and accesses the core configuration data of the missile system. The data is stored in the configuration area of ​​the Flash storage chip in the form of a structured binary file and serves as the basic data source and status record carrier for adaptive decision-making.

[0058] In practical applications, a primary-backup combined storage mechanism can be used to improve data storage security. For example, the primary storage uses NOR Flash chips, supporting byte-level reading and block-level erasure and writing, ensuring fast access to configuration data; the backup storage is synchronously stored in a Flash backup partition, which is hardware write-protected and only unlocked for reading when the primary partition data is corrupted or updates fail, preventing system paralysis due to configuration loss; for error correction and anti-tampering, a built-in ECC (Error Correction Code) error correction algorithm can correct 1-bit errors and detect 2-bit errors, adapting to the harsh conditions of electromagnetic interference and vibration in the missile environment; a CRC32 checksum and update timestamp are embedded in the file header, automatically verified each time access is made, preventing data from being illegally tampered with or damaged during transmission.

[0059] In the absence of external commands, the adaptive configuration file submodule provides data such as the default loading version, resource requirements, and operating rules, ensuring that the basic control software can be automatically loaded after the system is powered on without external intervention. After receiving command data (such as target version identifier and resource requirements) parsed by the external decision protocol, it converts it into hardware-recognizable configuration parameters (such as Flash storage address and DDR allocation range), providing the basis for the loading process. The adaptive configuration file submodule ensures that configuration data is not lost or damaged in extreme environments through primary and backup partition backup and checksum verification, providing data protection for system fault recovery.

[0060] (2) External Decision-Making Agreement Submodule

[0061] The external decision-making protocol submodule is a standardized interface unit for the adaptive decision-making module to interact with external devices. It defines the rules for the entire process of sending, receiving, verifying, and parsing instructions, ensuring the accuracy, security, and compatibility of instruction transmission, and avoiding decision-making errors caused by inconsistent instruction formats or transmission errors.

[0062] Figure 2 This is a schematic diagram illustrating the configuration file update process provided in an embodiment of the present invention. The adaptive configuration file update is the core process of dynamic loading, and is completed collaboratively by two sub-modules. The specific steps are as follows:

[0063] Step S201: After receiving the initialization completion and system kernel ready signals sent by the first-level boot, start the adaptive configuration file update process.

[0064] In the above steps, after the secondary boot receives the hardware initialization and system kernel ready signals sent by the primary boot, the adaptive decision module starts, the adaptive configuration file submodule completes self-verification and sends a configuration ready signal to the external decision protocol submodule, which synchronously requests to read the basic configuration and running parameter fields to prepare for the encapsulation of query instructions, marking the formal start of the adaptive configuration file update process.

[0065] Step S202: Send an inquiry command through the external bus interface and start the waiting timer.

[0066] In the above steps, the external decision-making protocol submodule reads parameters (such as computer ID, default loading version, total hardware resources, etc.) from the adaptive configuration file submodule, encapsulates the query command according to the protocol format, and sends it through the external bus. At the same time, it starts the query waiting timer set in the configuration file (default 50ms) and sends feedback to the adaptive configuration file submodule that the command has been sent, and the latter enters the waiting-to-update state.

[0067] Step S203: Receive external data and perform integrity and legality checks.

[0068] In the above steps, during the query waiting timer, the external decision protocol submodule continuously listens to the external bus to receive externally transmitted data frames. First, it performs integrity checks (such as checking the matching of frame header and trailer, the consistency of frame length with actual data length, and the correctness of CRC16 checksum). Then, it performs legality checks (such as verifying the consistency of device ID with onboard computer ID, whether the instruction type is a switching instruction, whether the target version identifier is in the configuration file version list, and the matching of sender permission code). If the checks pass, it extracts key parameters such as target version identifier and resource requirements and feeds them back to the adaptive configuration file submodule. If the checks fail, it reports the reason for the failure to that submodule.

[0069] Step S204: After the query waiting timer expires, determine whether a valid control software switching instruction is received based on the verification result of the external decision protocol submodule. If a valid control software switching instruction is received, update the adaptive configuration file and locate the target software based on the new configuration. If no instruction is received or the instruction verification fails, directly read the currently effective adaptive configuration file and locate the target software based on the default configuration.

[0070] In the above steps, the first scenario specifically includes: if the data has been received and verified, the adaptive configuration file submodule first backs up the current main partition configuration file to the backup partition and updates the backup identifier. Then, it modifies the main partition configuration file according to the target version identifier and resource requirement parameters in the instruction. After the update, the integrity is verified by comparing the CRC32 checksum. If the verification is consistent, it is marked as effective and the external decision protocol submodule sends a successful update feedback to the external device. If the verification is inconsistent, the original configuration is restored and the update failure and fault code are fed back.

[0071] In the above steps, the second scenario specifically includes: if no data is received or the verification fails, the adaptive configuration file submodule skips the update process, directly reads the currently effective configuration file of the main partition, extracts the default loading version and related parameters, and sends a signal to the external decision protocol submodule that it has not been updated and will adopt the current configuration.

[0072] The following example illustrates the operation process of each branch:

[0073] (1) Received and verified (a valid handover command was received within 50ms)

[0074] After receiving the verification results and target parameters, the adaptive configuration file submodule starts update preprocessing: it reads the current configuration file of the main partition, copies it completely to the backup partition, updates "backup identifier = 0x01" after copying, calculates the CRC32 checksum of the backup partition, and writes it into the security verification field; it sends a "backup complete" signal to the external decision protocol submodule, and the external decision protocol submodule pauses listening and waits for the update result;

[0075] Configuration file update execution: Modify the main partition configuration file according to the target parameters: 1) Update the "Default Load Version" in the Run Parameters field; 2) In the Resource Allocation field, match the resource parameters of the updated version (e.g., DDR start address 0x80020000, capacity 2MB, core 1 operation share 100%); 3) In the Security Verification field, update the main partition CRC32 checksum, the most recent update timestamp (current UTC time), and the update count +1;

[0076] Post-update verification: The adaptive configuration file submodule rereads the updated file on the main partition, calculates the CRC32 checksum, and compares it with the checksum written during the update. If they match, the file is marked as "effective" and a "successful update" signal is sent to the external decision protocol submodule. If they do not match (update failed), the updated content on the main partition is automatically erased, the original configuration file is restored from the backup partition, "update failed" is marked, the fault code is recorded, and sent to the external decision protocol submodule.

[0077] Feedback results: After receiving the "update success / failure" signal, the external decision-making protocol submodule encapsulates the "configuration update confirmation instruction", which includes "update result + fault code" and sends it to the external device.

[0078] (2) No data received or verification failed within 50ms

[0079] After the timer expires, the external decision-making protocol submodule sends a "no valid instruction" signal to the adaptive configuration file submodule. The adaptive configuration file submodule skips the update process, directly reads the configuration file of the current "effective status" of the main partition, and extracts the "default loaded version", "storage address", "resource allocation parameters", etc. It sends a "not updated, use the current configuration" signal to the external decision-making protocol submodule. The external decision-making protocol submodule does not need to provide feedback to the outside world.

[0080] Step S205: Move the target control software from the corresponding partition of Flash to DDR memory via the internal storage bus. After completing the data integrity verification, send a startup command to FMQL20S400 core 1 via the inter-core communication bus to trigger the software to run.

[0081] In the above steps, regardless of whether the adaptive configuration file has been updated, the adaptive configuration file submodule will extract the final effective core configuration parameters (including the target control software version identifier, Flash storage address, DDR running address, and resource allocation parameters), and send them to the software loading module through the secondary boot internal data bus to start the data transfer and loading process of the control software from Flash to DDR; at the same time, the external decision protocol submodule resumes external bus listening, reads the current software running version and status data from the adaptive configuration file submodule at fixed intervals (such as 100ms), encapsulates it into standard status feedback instructions, and sends them to external devices to ensure that the outside world can monitor the system's running status in real time.

[0082] Step S206: During the operation of the target software, the adaptive decision module continuously listens for external commands through the external bus interface while monitoring the software's operating status. When a new valid switching command is received, a stop command is immediately sent through the inter-core communication bus. After the resources are released, the adaptive configuration file update is triggered again to achieve online dynamic switching of the software version.

[0083] During the above steps, the adaptive decision-making module continuously executes dual monitoring logic during normal operation of the control software: On the one hand, the external decision-making protocol submodule constantly listens to the external bus. If it receives a valid control software switching command or configuration parameter modification command again, it immediately re-triggers the complete process of adaptive configuration file update; on the other hand, the adaptive configuration file submodule automatically performs a CRC32 self-verification of the main partition configuration file every 500ms. If data corruption is detected, it immediately restores the original configuration from the backup partition and sends a fault alarm command to the external device through the external decision-making protocol submodule to ensure configuration validity and system stability, and realize dynamic response and fault tolerance for configuration updates.

[0084] The secondary bootstrap system, acting as the upper-level control core, manages the entire lifecycle of the application software layer, including loading, running, switching, and stopping, providing it with the operational foundation and dynamic adjustment capabilities. The application software layer, as the functional execution carrier, relies on the secondary bootstrap system's resource allocation and command control to achieve specific application scenario tasks. Simultaneously, it forms a closed-loop interaction through status feedback. Together, they support the realization of the dynamic loading function of the onboard computer program.

[0085] like Figure 1 As shown, the application software layer serves as the functional execution carrier of the missile-borne system. Its core function is to carry dedicated control logic for different specific application scenarios. It includes multiple differentiated versions of control software (such as those for air-to-air and air-to-ground applications), each with complete task execution, hardware adaptation, and status feedback capabilities. It can implement specific application scenario functions under secondary guidance and control. The implementation method of the application software layer is as follows:

[0086] (1) For different specific application scenarios and tasks, write control software code respectively, and generate independent BIN format files after compilation and linking (such as each file containing a unique version identifier, code segment, data segment, runtime dependency parameters, etc.).

[0087] (2) The Flash storage chip of the missile computer is pre-divided into multiple independent software storage partitions. The starting address, storage capacity and access permissions of each partition are pre-defined in the adaptive configuration file to avoid storage conflicts between different versions of software.

[0088] (3) Using ground testing equipment or a data link for specific application scenarios, burn the BIN files of each version control software to the corresponding preset partition of Flash, and perform data integrity verification after burning to ensure that the files are not damaged;

[0089] (4) During operation, after receiving the startup command sent by the secondary boot, it loads and runs in core 1, calls the required hardware resources through the internal bus, and executes the corresponding specific application scenario tasks;

[0090] (5) Provide real-time feedback of running status data (such as task execution progress, fault codes, resource usage, etc.) to the secondary boot, receive and respond to the stop command of the secondary boot, and release the occupied hardware resources.

[0091] In summary, this invention provides a dynamic loading technology solution for missile-borne computer programs based on the FMQL platform. By combining two-level guidance with adaptive decision-making and other technologies, the missile-borne software is endowed with adaptive capabilities. It can achieve dynamic loading of programs in the case of the missile as a whole, that is, by modifying the adaptive configuration through the missile-to-ground interface, or by achieving online dynamic loading of programs through adaptive protocols during the operation of the missile-borne program. This enables the missile-borne system to maintain a high degree of operational flexibility in complex and ever-changing environments.

[0092] It should be understood that although the steps in the flowcharts in the accompanying drawings are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts in the accompanying drawings may include multiple steps or stages, which are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0093] It is understood that the same / similar parts between the various embodiments of the methods described above in this specification can be referred to each other. Each embodiment focuses on the differences from other embodiments, and relevant parts can be referred to the description of other method embodiments.

[0094] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0095] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A dynamic loading system for missile-borne computer programs, characterized in that, The system includes a boot software layer and an application software layer. Through the collaboration and adaptive decision-making mechanism between the two layers, the dynamic loading of the onboard computer program is realized. The boot software layer includes primary boot and secondary boot; The first-level bootloader is the underlying basic boot module of the missile-borne computer program dynamic loading architecture, which is used to implement core hardware resource configuration and system kernel loading; the second-level bootloader is the core control layer of the missile-borne computer program dynamic loading architecture; the operating environment of the second-level bootloader is the FMQL20S400 processor core 0 of the missile-borne computer, and the second-level bootloader exclusively uses the computing resources of the FMQL20S400 core 0 throughout the process and does not share the kernel with the application software layer; The secondary boot process includes a general hardware resource configuration module and an adaptive decision module, which work together to realize the functions of upper-layer application loading, dynamic resource allocation and online dynamic program loading. The adaptive decision-making module includes an adaptive configuration file submodule and an external decision-making protocol submodule; The adaptive configuration file submodule is a functional unit that stores, manages, and accesses the core configuration data of the system. The data is stored in the configuration area of ​​the Flash storage chip in the form of a structured binary file. The external decision-making protocol submodule is a standardized interface unit for the adaptive decision-making module to interact with external devices. The application software layer is used to carry the dedicated control logic for different specific application scenarios. It includes multiple differentiated versions of control software. Each version has complete task execution, hardware adaptation and status feedback capabilities, and can realize the functions of specified specific application scenarios under secondary guidance control. Updating the adaptive configuration file involves the following steps: After receiving the initialization completion and system kernel ready signals from the first-level boot process, the adaptive configuration file update process is initiated; a query command is sent through the external bus interface and a waiting timer is started; external data is received and its integrity and validity are verified. After the query waiting timer expires, the system determines whether to accept a legitimate control software switching command based on the verification result of the external decision protocol submodule. If a legitimate control software switching command is received, the system updates the adaptive configuration file and locates the target control software based on the new configuration. If no legitimate control software switching command is received or the legitimate control software switching command verification fails, the system directly reads the currently effective adaptive configuration file and locates the target control software based on the default configuration. The target control software is moved from the corresponding partition of Flash to DDR memory via the internal storage bus. After data integrity verification is completed, a startup command is sent to FMQL20S400 core 1 via the inter-core communication bus to trigger the software to run. During the operation of the target control software, the adaptive decision module continuously listens for external commands through the external bus interface while monitoring the software's operating status. When a new and valid control software switching command is received, a stop command is immediately sent through the inter-core communication bus. After the resources are released, the adaptive configuration file update is triggered again, realizing online dynamic switching of the software version.

2. The missile-borne computer program dynamic loading system according to claim 1, characterized in that, The core hardware resource configuration is used to perform basic configuration of the onboard computer hardware, eliminate the initial uncertainty after the hardware is powered on, and ensure that the hardware has the conditions to work. The system kernel loading is used to load the system's core kernel program into the runtime environment, providing underlying runtime support for secondary boot and application software layers.

3. The missile-borne computer program dynamic loading system according to claim 1, characterized in that, The general hardware resource configuration module is used to dynamically allocate, monitor the status and coordinate conflicts of general hardware resources according to the instructions of the adaptive decision module, so as to provide an adapted operating environment for different versions of control software in the application software layer.

Images