A dynamic loading reconstruction method for real-time running of embedded programs

Abstract

This invention discloses a dynamic loading and refactoring method for real-time running embedded programs. The refactoring method includes: extending the reception of modules to be loaded into the real-time running embedded program of aerospace equipment; processing the modules to be loaded; loading the modules to be loaded; and dynamically loading and modifying the executable code, static variables, global variables, and dynamic variables of the real-time running embedded program of the aerospace equipment. Memory management is efficient and reasonable. When a module to be loaded is received, system memory pool space is allocated as needed. After the operation is completed, unused module memory can be released according to parameters, avoiding memory leaks and ensuring efficient utilization of memory resources in the embedded system of aerospace equipment.

Description

Technical Field

[0001] This invention relates to the field of embedded program technology, and in particular to a dynamic loading and reconfiguration method for real-time running embedded programs. Background Technology

[0002] Embedded software in aerospace equipment faces core requirements for upgrades and maintenance during real-time operation. However, traditional technologies struggle to flexibly modify the executable code, static variables, global variables, and dynamic variables of embedded programs, as well as add and delete tasks and update and refactor functions without halting the overall operation of the equipment or interrupting the operating system. Furthermore, aerospace equipment demands extremely high real-time performance, stability, and reliability from its software. Therefore, there is an urgent need for a dynamic loading and refactoring technology for embedded programs adapted to aerospace scenarios to address the technical challenges of complex upgrade and maintenance operations, poor adaptability, and the inability to achieve precise dynamic modification of program elements in existing technologies.

[0003] Currently, the main approach to upgrading and modifying embedded programs is to use a system-wide shutdown flashing technique. This involves stopping the entire embedded system, burning the new program image to the hardware storage medium using a dedicated flashing tool, and then restarting the system to update the program. While some conventional industrial embedded scenarios have attempted simple dynamic modifications, these methods can only achieve simple adjustments to a small number of single variables and lack standardized module encapsulation and verification mechanisms.

[0004] Meanwhile, the existing technology for parsing and loading ELF format target files is only applicable to general computer systems. For real-time embedded operating systems of aerospace equipment, there is a lack of adapted segment loading, symbol table management and relocation mechanisms. Furthermore, the task management of traditional embedded systems is in a static mode, and the creation and deletion of tasks must be completed during the system initialization phase. Dynamic addition and deletion of tasks cannot be achieved during operation.

[0005] Existing embedded program modification technology lacks a complete module receiving, verification, and processing process, and there is no standardized definition of the data structure of the modules to be loaded. It is impossible to effectively verify and manage the modified content, making it difficult to meet the high reliability requirements of aerospace equipment.

[0006] Existing technologies can only replace the entire program image, and cannot perform fine-grained and targeted individual modifications to the executable code, static variables, global variables, and dynamic variables of embedded programs. They also cannot add or delete tasks or perform partial updates of functions during operation, resulting in extremely low flexibility and efficiency in upgrades and maintenance.

[0007] The general ELF file loading technology cannot be adapted to the real-time embedded operating system of aerospace equipment. It lacks segment allocation, symbol table integration, and relocation optimization for real-time systems, and cannot achieve dynamic loading and relocation of program code during runtime. It lacks standardized module design adapted to aerospace scenarios, and there is no unified data structure and verification mechanism for modules to be loaded. During the modification process, problems such as data errors and module incompatibility are prone to occur. Furthermore, there is no error verification and status return mechanism, and the reliability cannot meet the stringent requirements of aerospace equipment. Summary of the Invention

[0008] In view of the above problems, the present invention is proposed to provide a dynamic loading and reconfiguration method for real-time running embedded programs that overcomes or at least partially solves the above problems.

[0009] According to one aspect of the present invention, a dynamic loading and refactoring method for real-time running embedded programs is provided, the refactoring method comprising: Extend the reception of the module to be loaded into the embedded program that runs in real time in aerospace equipment; Modules to be loaded are being processed; Modules to be loaded are being loaded; Dynamic loading and modification of the executable code, static variables, global variables, and dynamic variables of embedded programs running in real time on aerospace equipment.

[0010] Optionally, the structure of the module to be loaded defines the name, length, type, check value, related task name, and number of parameters of the module to be loaded.

[0011] Optionally, the information on the module to be loaded records the usage of the module to be loaded in the system, including the name, type, length, loading time, code segment address, and length of the module to be loaded.

[0012] Optionally, the module to be loaded specifically receives the following: The module to be loaded is the processing object for dynamic loading and reconstruction. The receiving function consists of three sequentially executed parts: header acquisition, space allocation to be loaded, and relocation of the module to be loaded. After the module to be loaded is encapsulated according to the data structure, it is injected into the aerospace equipment runtime program through the network. The receiving function of the module to be loaded obtains the pointer of the data block and performs the receiving operation of the module to be loaded.

[0013] Optionally, the operation received by the module to be loaded specifically includes: The size of the module file to be loaded can be determined by the information in the header of the module file to be loaded. Call the memory allocation function to create a memory of sufficient size within the system memory pool; Call the memory copy function to move the module file to be loaded into the system memory pool and release the memory space occupied by the injected binary data block.

[0014] Optionally, the process of extending the received module in the embedded program running in real time on the aerospace equipment further includes: The received module to be loaded is checked, and a correct or incorrect status is returned based on the verification result; The checks include type checking and cumulative checksum verification. If any check fails, an error code is returned; otherwise, OK is returned. Type checking refers to whether the Type field in the header of the module to be loaded is a valid type value; The checksum check refers to whether the value of the checksum field in the header of the module to be loaded is equal to the sum of all bytes in the module to be loaded.

[0015] Optionally, the processing of the module to be loaded specifically includes: Get the type of the specified module to be loaded and return the type value to the user; Modify the value of a specified variable using the information and data provided in the module to be loaded; Using the relevant information and data of the task to be added provided in the module to be loaded, the new task function is injected into memory, relocated, and the new task is created and started to realize the addition of the task; Iterate through the deletion task information and perform the task deletion operation; By modifying the information of the function and related tasks, it is possible to modify any function.

[0016] Optionally, the loading of the module to be loaded specifically includes: Parse the ELF format target file, allocate loading space for the text, data, and bss segments in the file, and load them; During the loading process, the system symbol table is checked to confirm the use of external symbol values ​​in the target file, and the target file is relocated based on the symbol values.

[0017] Optionally, during the loading process, confirming the use of external symbol values ​​in the target file within the system symbol table and performing relocation processing on the target file based on the symbol values ​​specifically includes: First, based on the contents of the file header, create and initialize multiple index tables and other structures or arrays required to manage the loading process; Then, iterate through all sections, and according to the different types of sections, organize and fill the index contents of the loadable segment index table, symbol table index table, relocation information segment index table, and string table segment index table to complete the parsing of the file; After parsing, based on the index, the contents of the text, data, and bss segments in different sections are extracted and integrated to obtain the final size of the three segments. Space is allocated in the system memory pool for these three segments as the destination address for loading. The segments are moved from the module file to be loaded to the target board memory by memory copying. After the move is completed, the offset address and relocation padding data are determined according to the contents of the relocation information segment index table and the data of the system symbol table. The contents of the corresponding address unit on the target board memory are rewritten to complete the relocation of the program. At the same time, the newly added global variables in the target file are added to the system symbol table. Finally, the address, size, and loading time information of each segment are stored in the information storage structure, completing the entire file loading process.

[0018] This invention provides a dynamic loading and refactoring method for real-time running embedded programs. The refactoring method includes: extending the reception of modules to be loaded into the real-time running embedded program of aerospace equipment; processing the modules to be loaded; loading the modules to be loaded; and dynamically loading and modifying the executable code, static variables, global variables, and dynamic variables of the real-time running embedded program of the aerospace equipment. Memory management is efficient and reasonable. When a module to be loaded is received, system memory pool space is allocated as needed. After the operation is completed, unused module memory can be released according to parameters, avoiding memory leaks and ensuring efficient utilization of memory resources in the aerospace equipment embedded system.

[0019] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. 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.

[0021] Figure 1 A flowchart of a dynamic loading and refactoring method for real-time running embedded programs provided in an embodiment of the present invention; Figure 2 This is a flowchart of the module to be loaded receiving process provided in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the operation of receiving the module to be loaded, provided in an embodiment of the present invention. Figure 4 This is a schematic diagram illustrating the operation of processing the module to be loaded according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the operation of the module for processing and modifying variables to be loaded, provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the module structure to be loaded with modified variables provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of variable modification provided in an embodiment of the present invention; Figure 8 This is a schematic diagram illustrating the operation of the module for processing newly added tasks to be loaded, provided in an embodiment of the present invention. Figure 9 This is a schematic diagram of the structure of the new task to be loaded module provided in an embodiment of the present invention; Figure 10 This is a schematic diagram illustrating the operation of the module for processing and deleting tasks to be loaded, provided in an embodiment of the present invention. Figure 11 This is a schematic diagram of the module structure for deleting tasks to be loaded, provided in an embodiment of the present invention. Figure 12 This is a schematic diagram of the operation of the module to be loaded in the processing modification function provided in the embodiment of the present invention; Figure 13 This is a schematic diagram of the module structure to be loaded for the modified function provided in an embodiment of the present invention; Figure 14 This is a schematic diagram of loading and relocation operations provided in an embodiment of the present invention; Figure 15 This is a schematic diagram of loading and relocation provided for an embodiment of the present invention. Detailed Implementation

[0022] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0023] The terms "comprising" and "having," and any variations thereof, in the specification, embodiments, claims, and drawings of this invention are intended to cover non-exclusive inclusion, such as including a series of steps or units.

[0024] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0025] like Figure 1As shown, the present invention provides a dynamic loading and refactoring method for real-time running embedded programs. The refactoring method includes: extending the reception of the module to be loaded in the real-time running embedded program of aerospace equipment; processing the module to be loaded; loading the module to be loaded; and dynamically loading and modifying the executable code, static variables, global variables and dynamic variables of the real-time running embedded program of aerospace equipment.

[0026] This invention provides a dynamic loading and refactoring method for real-time running embedded programs. By extending three functional processes—receiving, processing, and loading of the module to be loaded—into the real-time running embedded program (including a real-time operating system) of aerospace equipment, it achieves dynamic loading and modification of the executable code, static variables, global variables, and dynamic variables of the real-time running embedded program of aerospace equipment. This enables support for embedded software refactoring at the aerospace equipment operating system level. Specifically, it includes the following: (1) Module to be loaded receives ① The data structure design of the module to be loaded is as follows: The header structure of the module to be loaded defines information such as the name, length, type, checksum, related task name, and number of parameters of the module to be loaded.

[0027] The header structure of the module to be loaded is defined as follows: typedefstruct patch_head { unsigned int Size; unsigned int Type; unsigned int CheckSum; unsigned int PatchName; unsigned int FileIndex; unsigned int Number; unsigned int Index; unsigned int Tnum; unsigned int Tname; unsigned int pad; PATCH_HEAD; The information about modules to be loaded records their usage within the system, including their name, type, length, loading time, code segment address, and length. The structure of this information is defined as follows: typedefstruct patch_recinfo { unsigned int name; unsigned int type; unsigned int size; unsigned int loadtime; unsigned int textaddr; unsigned int textsize; unsigned int dataaddr; unsigned int datasize; unsigned int bssaddr; unsigned int bsssize; PATCH_RECINFO; The ELF file header data structure defines information such as the ELF magic number, file machine byte length, data storage method, version, operating platform, ABI version, ELF relocation type, hardware platform, hardware platform version, entry address, segment table location and length, and number of segments.

[0028] The ELF file header structure is defined as follows: typedef struct { unsigned chare_ident[EI_NIDENT]; / * ident bytes * / Elf32_Halfe_type; / * file type * / Elf32_Halfe_machine; / * target machine * / Elf32_Worde_version; / * file version * / Elf32_Addre_entry; / * start address * / Elf32_Ofe_phoff; / * phdr file offset * / Elf32_Ofe_shoff; / * shdr file offset * / Elf32_Worde_flags; / * file flags * / Elf32_Halfe_ehsize; / * sizeof ehdr * / Elf32_Halfe_phentsize; / * sizeof phdr * / Elf32_Halfe_phnum; / * number phdrs * / Elf32_Halfe_shentsize; / * sizeof shdr * / Elf32_Halfe_shnum; / * number shdrs * / Elf32_Halfe_shstrndx; / * shdr string index * / Elf32_Ehdr; The code segment header data structure defines information such as the program entry address, the offset position within the code segment file, virtual addresses, file size, and alignment requirements. The code segment header data structure is defined as follows: / * Program header * / typedef struct { Elf32_Wordp_type; / * entry type * / Elf32_Offp_offset; / * file offset * / Elf32_Addrp_vaddr; / * virtual address * / Elf32_Addrp_paddr; / * physical address * / Elf32_Wordp_filesz; / * file size * / Elf32_Wordp_memsz; / * memory size * / Elf32_Wordp_flags; / * entry flags * / Elf32_Wordp_align; / * memory / file alignment * / Elf32_Phdr; The ELF segment descriptor structure defines information such as segment name, segment type, flags, virtual address, offset address, segment length, and address alignment. The segment descriptor structure is defined as follows: / * Section header * / typedef struct { Elf32_Wordsh_name; / * section name * / Elf32_Wordsh_type; / * SHT_... * / Elf32_Wordsh_flags; / * SHF_... * / Elf32_Addrsh_addr; / * virtual address * / Elf32_Offsh_offset; / * file offset * / Elf32_Wordsh_size; / * section size * / Elf32_Wordsh_link; / * misc info * / Elf32_Wordsh_info; / * misc info * / Elf32_Wordsh_addralign; / * memory alignment * / Elf32_Wordsh_entsize; / * entry size if table * / Elf32_Shdr; The ELF symbol table structure is used to record symbol relocation information, mainly including symbol name, corresponding value, symbol size, and symbol type. The symbol table structure is defined as follows: / * Symbol table * / typedef struct { Elf32_Wordst_name; Elf32_Addrst_value; Elf32_Wordst_size; unsigned charst_info; / * bind, type: LF_32_ST_ * / unsigned charst_other; Elf32_Halfst_shndx; / * SHN_... * / Elf32_Sym; The ELF relocation table is used to relocate symbols in an object file, specifically those references to absolute addresses in the code and data segments. The structure of the relocation table is defined as follows: / * Relocation * / typedef struct { Elf32_Addrr_offset; Elf32_Wordr_info; / * sym, type: ELF32_R_... * / Elf32_Rel; ② Module to be loaded receives The module to be loaded is the processing object for dynamic loading and refactoring. The receiving function consists of three sequentially executed parts: header acquisition, allocation of space to be loaded, and relocation of the module to be loaded. Figure 2 As shown. After the module to be loaded is encapsulated according to the above data structure, it is injected into the aerospace equipment runtime program via the network. The receiving function of the module to be loaded obtains a pointer to the data block and performs the receiving operation. First, the size of the module to be loaded file is determined through the information in the header of the module to be loaded file; then, the memory allocation function is called to create sufficient space of memory in the system memory pool; finally, the memory copy function is called to move the complete module to be loaded file to the system memory pool and release the memory space occupied by the injected receiving and storing binary data blocks, as shown. Figure 3 As shown.

[0029] ③ Verification of modules to be loaded This function is responsible for checking the received module to be loaded and returning a correct or incorrect status based on the verification result. The checks include type checking and checksum verification. An error code is returned if either check fails; otherwise, OK is returned. Type checking checks whether the Type field in the header of the module to be loaded is a valid type value. Checksum verification checks whether the value of the checksum field in the header of the module to be loaded is equal to the sum of all bytes in the module to be loaded.

[0030] (2) Processing of modules to be loaded This function processes modules that have already been verified and are ready to be loaded. Depending on the module type, different processing functions are called to load and execute the module. The process for processing modules to be loaded mainly consists of three steps: obtaining the type of the module to be loaded, calling the corresponding processing function based on the module type, and finally determining whether to release the memory of the module to be loaded based on the processing result and input parameters. Figure 4 As shown.

[0031] There are four types of modules to be loaded: modules for modifying variables, modules for adding tasks, modules for deleting tasks, and modules for modifying functions. This function first obtains the type of the module to be loaded, and then calls the corresponding module package processing function for processing according to the type. Finally, if the operation is successful and the user parameter requests deletion of the module to be loaded, the module to be loaded is deleted from memory, and the corresponding memory is released.

[0032] ① Obtaining the type of module to be loaded This function obtains the type of the specified module to be loaded and returns the type value to the user. The module type to be loaded is an enum data type, stored in the Type field of the module header. There are four types of modules to be loaded: modified variable, added task, deleted task, and modified function.

[0033] ② Processing of variables to be loaded This function uses information and data provided by the module to be loaded to modify the value of a specified variable. The modified variable has the following characteristics: There is no limit to the number of variables that can be modified; it is determined by the actual content of the module to be loaded. There are no restrictions on the type of the variable you want to modify; it can be a character, integer, array, structure, etc. The variable to be modified can be identified by its name or its physical address stored on the target board. If the variable name is used as the identifier, the variable must have a corresponding entry in the system symbol table; otherwise, an error will be reported.

[0034] This function consists of four sequentially executed parts: suspending related tasks, collecting variable modification information, modifying variables, and resuming related tasks. Figure 5 As shown.

[0035] This function processes modules of type "Modify Variable," whose type is determined by the Type field in its header. The content of the module to be loaded is structured as follows: Figure 6 As shown.

[0036] The module to be loaded first iterates through the variable-related tasks using the `tNum` and `tName` fields in its header, and suspends these tasks. These variable-related tasks are specified by the user when the module is created; they are tasks that the user deems relevant to the variable to be modified, must terminate before modification, and restart after modification. Suspending and restarting these tasks ensures that the variable modification takes effect within these tasks. Then, the module iterates through the `Number` and `Index` fields in its header, obtaining the variable name or its physical address through the variable information index. If the physical address is obtained directly, the process proceeds to the next step; if only the variable name is obtained, the symbol value is searched in the system symbol table to confirm the variable's physical address. After obtaining the physical address, the `vSize` field in the variable information index is used to overwrite the variable data (which is sequentially placed after the variable name) in the variable's physical address space, completing the variable value modification. A diagram illustrating variable modification is shown below. Figure 7 As shown.

[0037] ③ Processing of newly added tasks awaiting loading modules This function uses the relevant information and data provided by the module to be loaded to inject the new task function into memory, relocate it, create and start the new task, and implement the task addition functionality. The function for adding a new task must be modified with the `static` keyword to ensure function locality. The module implementation mainly involves two steps: first, loading and relocating the new function; and second, iterating through the task information and creating the corresponding task, such as... Figure 8 As shown.

[0038] The newly added task to be loaded module contains three parts: header information, newly added task information, and the contents of the ELF format file generated by the newly added task function. The structure of the newly added task to be loaded module is as follows: Figure 9As shown. The header of a newly added task to be loaded module contains the following information: the size of the module package to be loaded, checksum, type of the module package to be loaded (the type of the newly added task to be loaded module), module package number, number of new tasks, pointer to the name of the first new task, and padding code. The new task information includes the name, priority, task stack, task entry function, and four task parameters of each task to be added. This data is used to create new tasks. Except for the top-level task function, all new tasks are modified with `static`. When processing newly added task modules to be loaded, the loading and relocation module `os_patch_loadelf()` is first called to load the new task function into memory and relocate it. Then, based on the task name pointer and the number of tasks in the header information, all task information to be added is traversed. The entry address of the task function can be obtained from the system symbol table based on the task function name. The task creation function `taskCreate()` is called to create all new tasks. Finally, the system time of the module package to be loaded and the module package number to be loaded are added to the module loading information linked list.

[0039] ④ Processing the deletion of modules to be loaded This function uses the information about the task to be deleted provided in the module to be loaded to delete the task. The main steps in processing the task deletion in the module to be loaded are to traverse the task deletion information and perform the task deletion operation, such as... Figure 10 As shown.

[0040] The structure of the modules to be loaded for deleting tasks is as follows: Figure 11 As shown, it contains two parts: header information and the name of the task to be deleted. The header of the task to be deleted contains the following information: the size of the module package to be loaded, checksum, type of the module package to be loaded (the type of the module to be loaded in the deleted task), module package number, number of tasks to be deleted, pointer to the first deleted task name, and padding code. When processing the deletion of the task to be loaded, based on the task name pointer and the number of tasks in the header information, all task names are traversed. Based on the task name, the corresponding task ID is found in the operating system's task list, and then the task deletion function is called to delete the corresponding task. Finally, the system time of the module package to be loaded and the module package number to be loaded are added to the module loading information linked list.

[0041] ⑤ Modify the processing of modules to be loaded in the function. This function allows modification of any function by using information about the modification function and related tasks provided in the module to be loaded. The requirement is that the name of the modified function should be the original function name with "_1" appended. The main steps for handling the modification function type in the module are fourfold: first, iterate through the related tasks and suspend them; second, load and relocate the modification function; third, modify the original function; and finally, iterate through the related task information and restart these tasks. Figure 12 As shown.

[0042] The modified function to be loaded module contains four parts: header information, modified function information, related task information, and the contents of the ELF format file generated from the modified function file, such as... Figure 13 As shown. The header of the module to be loaded for the modification function contains the following information: the size of the module package to be loaded, the checksum, the type of the module package to be loaded (the type of the module to be loaded for the modification function), the module package number to be loaded, the number of modification functions, a pointer to the name of the first function, the number of related tasks, a pointer to the name of the first task, and the padding code.

[0043] When processing the modules to be loaded with modified functions, the process first iterates through all task names based on the task name pointer and number of tasks in the header information. Then, it finds the corresponding task ID in the operating system's task list based on the task name and calls the task suspension function to suspend these related tasks. Next, it calls the loading and relocation module `os_patch_loadelf()` to load the ELF file of the modified functions into memory and relocate it. After loading, it iterates through all functions based on the number of modified functions and function name pointers in the header information. Using the system symbol table, it finds the address of the original function and the address of the function with the same name prefixed with "_1". It then modifies the program at the location of the original function to call the new function with the same name prefixed with "_1". Finally, it calls the task restart function to restart all related tasks. Finally, it adds the system time and module package number of the module to be loaded to the module loading information chain.

[0044] (3) Loading of the module to be loaded This function parses ELF format target files, allocates loading space for the text, data, and bss segments, and loads them. During loading, it checks the system symbol table for external symbol values ​​used in the target file and performs relocation processing based on these values. Simultaneously, it adds newly added global symbols from the target file to the system symbol table. Finally, it saves the load address, load segment length, and other information about the modules to be loaded, providing this information to the "Get Module Information to be Loaded" module. This module's implementation consists of five sequentially executed parts: file header parsing, index table setting, copy loading, relocation, and information storage. Figure 14 As shown.

[0045] File loading first requires creating and initializing multiple index tables and other structures or arrays to manage the loading process based on the file header content. Then, it iterates through all sections, organizing and filling the indexes of the loadable segment index table, symbol table index table, relocation information segment index table, and string table segment index table according to the different section types, completing the file parsing. After parsing, based on the indexes, the contents of the text, data, and bss segments within different sections are extracted and integrated to obtain the final size of the three segments. Space is allocated in the system memory pool for these three segments as the destination addresses for loading, and the segments are moved from the file to be loaded to the target board memory using memory copying. After the movement is complete, based on the contents of the relocation information segment index table and the data in the system symbol table, the offset address and relocation padding data are determined, and the contents of the corresponding address units in the target board memory are rewritten to complete the program relocation. Simultaneously, newly added global variables in the target file are added to the system symbol table. Finally, the addresses, sizes, and loading times of each loaded segment are stored in the information storage structure, completing the entire file loading process. Figure 15 As shown.

[0046] The number of loaded modules is recorded by a global variable maintained by the system. This variable is incremented by 1 each time a module is successfully loaded. Loaded modules are numbered in the order of loading (1, 2...n) and identified by their module numbers. Information about a specified module number can be returned, including loading time and segment information.

[0047] Beneficial effects: (1) Supports dynamic reconfiguration without downtime. Without stopping the embedded operating system and overall business operation of aerospace equipment, the dynamic modification and reconfiguration of variables, functions and tasks can be completed, ensuring the continuity and real-time performance of aerospace missions.

[0048] (2) It has strong fine-grained modification capabilities, and can modify any number of static variables, global variables, and dynamic variables of any type (character, integer, array, structure, etc.). It supports local updates of functions and dynamic addition / deletion of tasks without replacing the entire program image, which greatly improves the efficiency and flexibility of upgrade and maintenance.

[0049] (3) Standardized module design and strict verification: a unified header, information record and ELF related data structure for the module to be loaded are defined. After the module is received, it is verified by type check and cumulative verification to ensure the correctness of the module data. At the same time, the verification result returns a clear status code to meet the high reliability requirements of aerospace equipment.

[0050] (4) Software refactoring support is implemented at the operating system level, and the dynamic loading and refactoring of embedded programs is realized from the bottom layer of the system, rather than simple adjustments at the upper application layer. The modification effect is more thorough and adapts to the underlying architecture requirements of embedded software for aerospace equipment.

[0051] (5) Memory management is efficient and reasonable. When the module to be loaded is received, the system memory pool space is allocated as needed. After the operation is completed, the memory of the useless module can be released according to the parameters to avoid memory leakage and ensure the efficient use of memory resources of the embedded system of aerospace equipment.

[0052] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A dynamic loading reconfiguration method for running an embedded program in real time, characterized in that, The reconstruction method includes: Extend the reception of the module to be loaded into the embedded program that runs in real time in aerospace equipment; Modules to be loaded are being processed; Modules to be loaded are being loaded; Dynamic loading and modification of the executable code, static variables, global variables, and dynamic variables of embedded programs running in real time on aerospace equipment.

2. The dynamic loading and reconstruction method for running an embedded program in real time according to claim 1, wherein, The structure of the module to be loaded defines the module name, length, type, check value, related task name, and number of parameters.

3. The dynamic loading and reconstruction method for running an embedded program in real time according to claim 1, wherein, The information about the module to be loaded records the usage of the module in the system, including the name, type, length, loading time, code segment address, and length of the module to be loaded.

4. The dynamic loading and reconstruction method for running an embedded program in real time according to claim 1, wherein, The specific components received by the module to be loaded include: The module to be loaded is the processing object for dynamic loading and reconstruction. The receiving function consists of three sequentially executed parts: header acquisition, space allocation to be loaded, and relocation of the module to be loaded. After the module to be loaded is encapsulated according to the data structure, it is injected into the aerospace equipment runtime program through the network. The receiving function of the module to be loaded obtains the pointer of the data block and performs the receiving operation of the module to be loaded.

5. The dynamic loading and reconstruction method for running an embedded program in real time according to claim 4, wherein, The specific operations received by the module to be loaded include: The size of the module file to be loaded can be determined by the information in the header of the module file to be loaded. Call the memory allocation function to create a memory of sufficient size within the system memory pool; Call the memory copy function to move the module file to be loaded into the system memory pool and release the memory space occupied by the injected binary data block.

6. The dynamic loading and reconstruction method for running an embedded program in real time according to claim 1, wherein, The process of extending the received module in the embedded program running in real time on aerospace equipment also includes: The received module to be loaded is checked, and a correct or incorrect status is returned based on the verification result; The checks include type checking and cumulative checksum verification. If any check fails, an error code is returned; otherwise, OK is returned. Type checking refers to whether the Type field in the header of the module to be loaded is a valid type value; The checksum check refers to whether the value of the checksum field in the header of the module to be loaded is equal to the sum of all bytes in the module to be loaded.

7. The dynamic loading and reconstruction method for running an embedded program in real time according to claim 6, wherein, The specific processing of the module to be loaded includes: Get the type of the specified module to be loaded and return the type value to the user; Modify the value of a specified variable using the information and data provided in the module to be loaded; Using the relevant information and data of the task to be added provided in the module to be loaded, the new task function is injected into memory, relocated, and the new task is created and started to realize the addition of the task; Iterate through the deletion task information and perform the task deletion operation; By modifying the information of the function and related tasks, it is possible to modify any function.

8. The dynamic loading and reconstruction method for running an embedded program in real time according to claim 1, wherein, The loading of the module to be loaded specifically includes: Parse the ELF format target file, allocate loading space for the text, data, and bss segments in the file, and load them; During the loading process, the system symbol table is checked to confirm the use of external symbol values ​​in the target file, and the target file is relocated based on the symbol values.

9. The dynamic loading and reconstruction method for running an embedded program in real time according to claim 8, wherein, During the loading process, the use of external symbol values ​​in the target file is confirmed in the system symbol table, and the target file is relocated based on the symbol values. This specifically includes: First, based on the contents of the file header, create and initialize multiple index tables and other structures or arrays required to manage the loading process; Then, iterate through all sections, and according to the different types of sections, organize and fill the index contents of the loadable segment index table, symbol table index table, relocation information segment index table, and string table segment index table to complete the parsing of the file; After parsing, based on the index, the contents of the text, data, and bss segments in different sections are extracted and integrated to obtain the final size of the three segments. Space is allocated in the system memory pool for these three segments as the destination address for loading. The segments are moved from the module file to be loaded to the target board memory by memory copying. After the move is completed, the offset address and relocation padding data are determined according to the contents of the relocation information segment index table and the data of the system symbol table. The contents of the corresponding address unit on the target board memory are rewritten to complete the relocation of the program. At the same time, the newly added global variables in the target file are added to the system symbol table. Finally, the address, size, and loading time information of each segment are stored in the information storage structure, completing the entire file loading process.

Images