A fault-tolerant method for onboard software EDAC for COTS platform

Abstract

A spaceborne software EDAC fault-tolerance method for COTS platforms is proposed. Based on the spaceborne EDAC hardware implementation, an EDAC verification module and checksum are designed. The checksum uses Hamming code, with each executable codeword being 32 bits long and the checksum being 7 bits, achieving a one-to-two verification function. Through executable code segment instrumentation, EDAC verification module call statements are inserted before the call statements of each module in the original executable code, enabling EDAC verification to be completed before the called module executes. The checksum of each instrumented executable code is calculated and stored as part of the program area. An improved approach of "running code priority verification" is adopted, combining pre-scheduling verification and idle-period verification to perform EDAC verification on the executable code. Simultaneously, a copy of the EDAC algorithm is stored in the program storage area, enabling mutual verification between the two EDAC algorithm modules to ensure the correctness of the EDAC module itself.

Description

TECHNICAL FIELD

[0001] The application belongs to the field of satellite-borne software design and relates to an EDAC fault-tolerant method for satellite-borne software. BACKGROUND

[0002] With the increasing complexity of the space environment, the application mode of the spacecraft in orbit is constantly enriched. On the basis of traditional spacecraft attitude measurement control, it is necessary to gradually enhance the perception and prediction of the space situation, and to independently carry out task planning and implementation according to the perception results, which puts forward higher requirements for the autonomous ability of the spacecraft in orbit. As the main carrier for realizing the functions of the spacecraft, the complexity of the satellite-borne software is constantly increasing. At the same time, the functions such as situation awareness and understanding involve real-time calculation and fusion processing of a large amount of data, which also requires more powerful on-orbit data processing capability.

[0003] On the other hand, in order to cope with the harsh space radiation environment and the high reliability requirement of spaceflight, existing satellite-borne computers generally adopt anti-radiation reinforcement measures, but their operation processing performance is far behind that of commercial off-the-shelf (COTS) devices, which is difficult to meet the demand of high-performance computing. Although COTS devices have great performance advantages, their lack of anti-radiation capability also makes it difficult to be directly applied. Therefore, it is of great practical significance to play the role of COTS devices in the satellite-borne environment at a low cost and high reliability.

[0004] The current satellite-borne computer fault-tolerant technology mainly relies on hardware fault-tolerant and software fault-tolerant.

[0005] Hardware fault-tolerant generally increases fault-tolerant design in the processor and storage unit. During the calculation process, hardware fault-tolerant can be achieved by designing a voter or a watchdog. On the one hand, it selects the majority of the same output as the actual result by adopting majority voting. On the other hand, in the face of software running abnormally or running away, it uses a watchdog timer to pull the program back from the abnormal state in time. In the data access process, hardware fault-tolerant can be achieved by using the redundancy check method. Typical satellite-borne computing units (such as SoC2008, BM3803, SOC2012, etc.) all use fault-tolerant strategies such as parity check, triple modular redundancy, and on-chip EDAC at the hardware level.

[0006] Software fault tolerance is generally achieved by adding fault tolerance measures in the software design and software compilation stages. The design stage fault tolerance methods include N-version and recovery block methods, and corresponding fault tolerance algorithm design. The most important fault tolerance algorithm is the software EDAC method, which checks the execution code by simulating the hardware EDAC mechanism, thereby detecting and correcting errors. The software compilation stage inserts fault tolerance instructions at specific locations in the code by improving the compiler. The REE program of JPL in the United States and the ARGOS experiment of the Reliability Computing Center of Stanford University have proposed several detailed compilation fault tolerance algorithms. Among them, EDDI and ED4I are relatively well-known compilation fault tolerance algorithms. EDDI and ED4I perform instruction replication at the assembly language level and perform redundant comparison before each instruction is stored to ensure the consistency of the calculation results. Fault tolerance compilation is divided into data flow protection technology and control flow protection technology according to the content to be protected. Typical data flow protection methods include EDDI, ED4I, VAR, etc. Typical control flow protection methods include CFCSS, YACCA, CEDA, etc.

[0007] In combination with the current needs in the field of spaceborne, the main problems of the above fault tolerance methods are as follows:

[0008] (1) Hardware fault tolerance does not require additional software overhead and has high reliability, but the cost of space-grade computing products with hardware fault tolerance mechanisms is high, increasing the cost of acquisition and application. At the same time, the performance of space products cannot be compared with that of current COTS devices. Therefore, using hardware fault tolerance cannot meet the current and future needs of space intelligent applications.

[0009] (2) Fault tolerance compilation methods all bring software runtime and space overhead. For example, in EDDI, the time overhead of software fault tolerance is as high as 170%; the space overhead of source-to-source compilation fault tolerance is 2.9 times, and the time overhead is as high as 2.6 times. From the implementation mechanism, fault tolerance compilation methods are still mainly based on the correctness of data flow and control flow, i.e., only the abnormality of data or control flow can be determined by inserting checks, etc., but error correction cannot be achieved. In the software design or compilation stage, the program execution branch direction after the occurrence of an exception needs to be considered.

[0010] (3) Software error detection and correction methods can partially implement EDAC functions compared with hardware EDAC. From the implementation method of the research, the EDAC implementation logic separates the program execution, program waiting, and program EDAC verification into three links. The proportion of program execution and program waiting time is high, and this process has no refresh to ensure protection against SEU, and the fault tolerance effect still needs to be improved. At the same time, the EDAC error detection and correction content is weakly related to the current executing program, and cannot guarantee in real time whether the program to be executed has a problem.

[0011] Based on the above analysis, existing fault-tolerant methods are not suitable for spaceborne systems built on COTS. Summary of the Invention

[0012] The technical problem solved by this invention is to overcome the shortcomings of the prior art and provide a software EDAC design method based on the COTS platform, which can realize periodic automatic error detection and correction of on-orbit running code segments. While reducing system overhead, it can effectively detect and correct single-event reversal anomalies, ensuring the continuous and normal operation of onboard software.

[0013] The technical solution of this invention is: an EDAC fault-tolerant method for onboard software on a COTS platform, which uses a combination of pre-scheduling verification and idle period verification to perform EDAC verification on all executable code of the onboard software, wherein:

[0014] The aforementioned pre-scheduling verification of software modules involves calling the EDAC verification module to verify all executable code generated by the module before each software module is executed, ensuring that all executable code is correct before execution.

[0015] The aforementioned idle time period verification utilizes the processor's idle time to periodically verify all executable software code from beginning to end. Each cycle verifies a corresponding length of code, ensuring that the verification of all executable code of the software modules is completed at regular intervals.

[0016] Furthermore, the step of first verifying all executable code generated by the compiled module by calling the EDAC verification module is as follows: by instrumenting the program segments of the original executable code of the software, the start address and end address of the program segment are obtained from the Mapfile file, and the corresponding program segment content is found in the original executable code according to the address. The module call statements in the program segment are traversed, and the start address and end address of the called module are obtained through symbol resolution. The statement calling the EDAC verification module is inserted before the call statement, and the start address and end address of the called module are used as the call parameters, so that the EDAC verification of the called module is completed before the execution of each called module.

[0017] Furthermore, the EDAC verification module stores two copies in the program storage area and designs two separately running verification tasks. The two separately running verification tasks run alternately, respectively verifying and refreshing the program segments in the two EDAC verification modules.

[0018] Furthermore, the EDAC verification module uses a (39:32) Hamming code for EDAC fault tolerance, where the executable code has a codeword length of 32 bits and the EDAC check code has 7 bits, for a total of 39 bits, to achieve the function of correcting one error and checking two errors.

[0019] Furthermore, the EDAC checksum is also allocated a 32-bit address space, with the lower 7 bits being the valid checksum and the higher 25 bits being masked.

[0020] Furthermore, the EDAC checksum, as part of the executable code, is soldered into the memory chip along with the executable code program segment and data segment. The checksum is stored in a separate memory space, located after the memory addresses of the program segment and data segment. Before the software runs, the boot software moves the contents of the program segment and checksum segment to the TEXT segment address space in memory.

[0021] The advantages of this invention compared to the prior art are:

[0022] (1) The method of the present invention adopts the improved idea of ​​"running code priority verification", which makes the interval between the EDAC verification process and the subsequent execution of code run smaller, so as to reduce the possibility of single-event inversion during this period of time, and is suitable for application fields with high reliability and high security requirements such as spacecraft.

[0023] (2) The method of the present invention comprehensively considers the combined requirements of the reliability of software task operation in embedded environment and the reliability of the verification software itself. By designing dual EDAC verification software and adding two independent tasks, the EDAC software is protected by interleaving during the intervals between normal software operation, thereby further enhancing the overall reliability of the software. Attached Figure Description

[0024] Figure 1 This is the overall design diagram of the EDAC fault-tolerant method in the software of this invention;

[0025] Figure 2 This is a schematic diagram of the executable code segment instrumentation for pre-scheduling verification of software modules according to the present invention;

[0026] Figure 3 This is a design drawing for storing the software program of this invention;

[0027] Figure 4 This is a schematic diagram of the EDAC software operation design of the present invention. Detailed Implementation

[0028] The present invention will be further described in detail below with reference to the accompanying drawings.

[0029] This invention discloses an EDAC fault-tolerant method for onboard software on the COTS platform, covering both the software generation process and the on-orbit operation process. The included modules and their interrelationships are described below. Figure 1 The implementation process is as follows:

[0030] (1) After the source code of the spaceborne software is compiled by the compiler, the original executable code of the spaceborne software and the corresponding Mapfile file are formed. The two are used as the input of this method. The executable code contains the actual contents of the program segment and the data segment. When the software is soldered, the two are stored continuously in the FLASH / EEPROM and other storage chips. Before the software runs, the boot software moves the two into memory and runs them. The Mapfile file contains the address information of each module in the program segment and each variable in the data segment of the executable code.

[0031] (2) Executable code segment instrumentation: Obtain the start and end addresses of the program segment from the Mapfile and locate the corresponding program segment content in the original executable code based on these addresses. This is done by traversing the module call statements within the program segment, i.e., searching for CALL statements and the modules they call. Based on the Mapfile, obtain the start and end addresses of the called module through symbol resolution. Insert a statement calling the EDAC verification module before each CALL statement, using the start and end addresses of the called module as call parameters. Simultaneously, based on the instrumented program segment content, update the address information of each module in the program segment within the Mapfile. The instrumentation method is as follows: Figure 2 As shown.

[0032] (3) Error Correction Encoding for Executable Code Segments: In the instrumented program segments, each executable code line has a codeword length of 32 bits. A corresponding (39:32) Hamming code is designed for each executable code line, where the executable code codeword length is 32 bits and the check code is 7 bits, totaling 39 bits, which can achieve the function of one-to-two error correction and two-to-correction. To ensure processor operating efficiency, a 32-bit address space is also allocated to each check code, with the lower 7 bits being the valid check code and the higher 25 bits being masked.

[0033] (4) Executable Code Storage Design: The checksum added in step (3) is incorporated as part of the executable code and soldered onto the memory chip along with the instrumented program segment and executable code data segment. A separate storage space is allocated for the checksum, storing it consecutively after the storage addresses of the instrumented program segment and executable code data segment. Before software execution, the bootloader moves the program segment and checksum segment contents to the TEXT segment address space in memory, moves the data segment to the DATA segment address space in memory, and maintains the existing BSS segment. After these operations are completed, the software begins execution from the starting address of the TEXT segment. Figure 3 As shown.

[0034] (5) Self-verification of the algorithm module: Considering that the EDAC code is also executed as a special task in the program storage area and may also have the possibility of single-particle flip, it is necessary to ensure its normal operation. For this purpose, two copies of the EDAC algorithm module are stored in the program storage area: EDAC Zone 1 and EDAC Zone 2. Two separate tasks are designed to run at the beginning of each cycle of the normal software task. The two tasks are started and run once respectively to realize mutual verification between the two EDAC algorithm modules and ensure the correctness of the EDAC module itself.

[0035] (6) Software module pre-scheduling verification: After step (5), normal software tasks begin scheduling. Since the executable code segment instrumentation operation has been completed in software step (2), before each software module is called and executed, the EDAC algorithm module will be called first to verify all executable code contained in the calling module.

[0036] (7) Software module execution: After the verification of the calling module is completed in step (6), the calling module is executed normally. Then, according to the program logic, the subsequent calling modules are verified and executed, and steps (6) and (7) are executed in a loop until all modules called by the current task are completed and the processor enters an idle period.

[0037] (8) Idle Period Software Verification: After the software task scheduling and execution, the processor enters the idle period and initiates the idle period software verification task to perform cyclic verification of all executable code from beginning to end. The code of a corresponding length is verified each cycle according to the idle time, ensuring that the entire code undergoes a comprehensive verification at regular intervals. The overall software execution and verification process is as follows: Figure 4 As shown.

[0038] The contents not described in detail in this specification are common knowledge to those skilled in the art.

Claims

1. A COTS platform oriented spaceborne software EDAC fault-tolerant method, characterized in that: The EDAC check is performed on all executable codes of the satellite software by combining the pre-module check and the idle period check. The pre-module check is performed before each software module is executed, and the EDAC check module is called to check all executable codes generated by the module, and the executable codes are ensured to be correct before the module is executed. The idle period check is performed by periodically checking all executable codes from the beginning to the end during the idle time of the processor, and the length of the code checked in each period is ensured to be completed once every certain period of time.

2. The COTS platform oriented on-board software EDAC fault-tolerant method according to claim 1, characterized in that: The executable codes generated by the module are checked by the EDAC check module, and the executable codes are found in the original executable code according to the address obtained from the Mapfile file, the module call statements in the program segment are traversed, the start address and the end address of the module are obtained by symbol analysis, the statement of calling the EDAC check module is inserted before the call statement, and the start address and the end address of the module are used as the calling parameters to realize the EDAC check of the module before the module is executed.

3. The COTS platform oriented on-board software EDAC fault-tolerant method according to claim 1 or 2, characterized in that: The EDAC check module stores two copies in the program storage area, and two separate check tasks are designed to run alternately to check and refresh the program segment in the two EDAC check modules.

4. The COTS platform oriented on-board software EDAC fault-tolerant method according to claim 3, characterized in that: The EDAC check module uses (39:32) Hamming code for EDAC fault tolerance, wherein the code word length of the executable code is 32 bits, the EDAC check code is 7 bits, and the total length is 39 bits, and the function of correcting one error and detecting two errors is realized.

5. The COTS platform oriented on-board software EDAC fault-tolerant method according to claim 4, characterized in that: The EDAC check code also allocates 32-bit address space, and the lower 7 bits are effective check codes and the upper 25 bits are masks.

6. The COTS platform oriented on-board software EDAC fault-tolerant method according to claim 5, characterized in that: The EDAC check code is part of the executable code, and the executable code program segment and the data segment are welded into the storage chip together, wherein the check code separately opens a storage space and is stored after the storage addresses of the program segment and the data segment, and the contents of the program segment and the check segment are moved to the TEXT segment address space in the memory by the boot software before the software is run.

Images