A method for on-board software load balancing of a multi-core CPU

Abstract

The application discloses a kind of on-orbit software load balancing methods of multi-core CPU, comprising the following steps: S1, thread pool is formed by the functional item abstraction of on-orbit software;S2, multi-core CPU is provided with at least 4 cores, wherein the algorithm thread, I / O thread is respectively limited in two CPU cores, the rest thread is set soft affinity, and according to the busy state of the rest CPU core, it is selected to run in corresponding CPU core;S3, algorithm thread, I / O thread, remote telemetry thread carry out data interaction by shared variable, and the competition problem between threads is solved by protecting shared variable by mutual exclusion, condition variable;S4, when on-orbit software needs to be programmed on-orbit, main thread stops corresponding thread, replaces old shared library with upgraded shared library, and restarts thread operation;Or terminate corresponding thread, add new shared library to specified position, recreate the thread, and open and load new shared library in thread operation.

Description

Technical Field

[0001] This invention relates to onboard software development technology for multi-core CPUs, and particularly to an onboard software load balancing method for multi-core CPUs. Background Technology

[0002] Onboard software is a crucial component of a satellite system. Traditional onboard software development techniques employ a single CPU and single thread approach. The software architecture is designed based on data flow, with threads running at fixed intervals in a loop from the beginning to the end of the software. Single-threaded software runs on a single CPU, failing to leverage the concurrency advantages of multi-core CPUs. All software functionalities, including I / O events with long response times, require thread querying and processing, resulting in long software execution cycles. The actual computational and control accuracy of the algorithm is inferior to that of the mathematical model simulation; the software reliability is also low, as a problem in any module can cause the onboard mission to abort. Summary of the Invention

[0003] The purpose of this invention is to provide an on-board software load balancing method for multi-core CPUs, which can be abstracted into a thread pool, allowing multiple threads to run concurrently on a multi-core CPU.

[0004] To achieve the above objectives, the present invention is implemented through the following technical solution:

[0005] A method for on-board software load balancing of multi-core CPUs, characterized by the following steps:

[0006] S1, a thread pool is formed by abstracting the functional items of the on-board software. The thread pool includes the main thread, algorithm thread, I / O thread, remote control and telemetry thread and emergency thread.

[0007] S2, the multi-core CPU has at least 4 cores, wherein the algorithm thread and I / O thread are each limited to two CPU cores, and the remaining threads are set with soft affinity and select to run on the corresponding CPU core according to the busy status of the remaining CPU cores.

[0008] S3, the algorithm thread performs algorithm calculations for attitude determination, navigation, and control output. The algorithm thread, I / O thread, and remote control and telemetry thread interact with data through shared variables. Mutexes and condition variables are used to protect the shared variables and solve the problem of competition between threads.

[0009] S4: When onboard software needs to be programmed in orbit, the main thread stops the corresponding thread, replaces the old shared library with the upgraded shared library, and restarts the thread; or it terminates the corresponding thread, adds the new shared library to the specified location, recreates the thread, and loads the new shared library while the thread is running.

[0010] Furthermore, in step S1, the main thread can create other threads, which can be stopped, restarted, or terminated by sending signals.

[0011] Furthermore, during normal tasks, the main thread creates algorithm threads, I / O threads, and remote control and telemetry threads. If the main thread receives the same hardware error signal more than twice within 1 second, it sends a kill signal to kill the algorithm thread and creates an emergency thread, and the on-board mission enters emergency processing.

[0012] Furthermore, step S3 also includes:

[0013] After the algorithm thread completes the control output calculation, it sends a signal to the I / O thread. Upon receiving the signal, the I / O thread executes the output.

[0014] I / O threads use signal-driven operations to satisfy data transmission and reception of multiple I / O ports, and can be used for master-slave communication or blind transmission communication with lower-level machines.

[0015] After receiving the bet from the ground, the remote telemetry thread updates the bet count in the shared variables and simultaneously sends the shared variables as telemetry packets to the ground.

[0016] Furthermore, step S4 also includes:

[0017] When an onboard mission enters an emergency phase, after the onboard program is updated, the main thread can terminate the emergency thread, recreate the algorithm thread, and the onboard system can resume normal operations.

[0018] Compared with the prior art, the present invention has the following advantages:

[0019] Multi-threaded operations are dynamically allocated across multiple CPUs, resulting in balanced CPU utilization and optimized efficiency.

[0020] Multithreading enables parallel processing, shortening the step size of on-board mission execution and improving the actual computational and control accuracy of the algorithm.

[0021] The software abstracts different functional items into thread pools. Traps or faults triggered during software operation will terminate or stop individual threads, minimizing the impact on the operation of other threads.

[0022] The I / O port data transmission and reception is managed by software interrupts, which has high real-time performance in receiving and processing data and consumes less CPU time. Unlike polling, it does not consume too much CPU time. At the same time, it breaks through the limitation of the number of hardware interrupts and can theoretically receive and process data from any number of I / O ports.

[0023] Traditional on-orbit programming techniques typically involve injecting new code segments into either the original address space or a new address space, followed by a jump to the new address at the original call location. The CPU must transfer control to the bootloader before on-orbit programming can proceed, a cumbersome and error-prone process. This invention proposes a shared library approach for on-orbit programming, where a thread simply opens a new shared library to achieve the same on-orbit programming effect. Attached Figure Description

[0024] Figure 1 This is a flowchart of an on-board software load balancing method for a multi-core CPU according to the present invention.

[0025] Figure 2 This invention provides a scheduling relationship diagram for a multi-core CPU and multiple threads.

[0026] Figure 3 A schematic diagram of the address space partitioning of the memory;

[0027] Figure 4 A diagram illustrating how to protect access to a shared variable area using a mutex;

[0028] Figure 5 This is a diagram illustrating signal synchronization between threads. Detailed Implementation

[0029] The present invention will be further described below with reference to the accompanying drawings and by providing a detailed description of a preferred embodiment.

[0030] like Figure 1 , 2 As shown, an on-board software load balancing method for multi-core CPUs includes the following steps:

[0031] S1, a thread pool is formed by abstracting the functional items of the on-board software. The thread pool includes the main thread, algorithm thread, I / O thread, remote control and telemetry thread and emergency thread.

[0032] S2, the multi-core CPU has at least 4 cores, wherein the algorithm thread and I / O thread are each limited to two CPU cores, and the remaining threads are set with soft affinity and select to run on the corresponding CPU core according to the busy status of the remaining CPU cores.

[0033] S3, the algorithm thread performs algorithm calculations for attitude determination, navigation, and control output. The algorithm thread, I / O thread, and remote control and telemetry thread interact with data through shared variables. Mutexes and condition variables are used to protect the shared variables and solve the problem of competition between threads.

[0034] S4: When onboard software needs to be programmed in orbit, the main thread stops the corresponding thread, replaces the old shared library with the upgraded shared library, and restarts the thread; or it terminates the corresponding thread, adds the new shared library to the specified location, recreates the thread, and loads the new shared library while the thread is running.

[0035] In step S1, the main thread creates other threads, which can be stopped, restarted, or terminated by sending signals.

[0036] During normal tasks, the main thread creates algorithm threads, I / O threads, and remote control and telemetry threads to manage signals generated by hardware errors. If the main thread receives the same hardware error signal more than twice within 1 second, it sends a kill signal to kill the algorithm thread and creates an emergency thread, and the on-board mission enters emergency processing.

[0037] The algorithm described above restricts the threads to CPU0, the I / O threads to CPU1, and the remaining threads are set with soft affinity and selected to run on the corresponding CPU core according to the busy status of CPU2 and CPU3.

[0038] like Figure 3 As shown, the code segment contains the entry address function of the thread. Different threads have different entry addresses. The thread stack is unique to each thread. The algorithm thread stack is allocated at the lowest address, and there is more space to expand downwards. The software needs to be refactored into a shared library. The space location is shown in the figure.

[0039] like Figure 4 As shown, step S3 further includes:

[0040] After the algorithm thread completes the control output calculation, it sends a signal to the I / O thread. Upon receiving the signal, the I / O thread executes the output.

[0041] I / O threads use signal-driven operations to satisfy data transmission and reception of multiple I / O ports, and can be used for master-slave communication or blind transmission communication with lower-level machines.

[0042] After receiving the bet from the ground, the remote telemetry thread updates the bet count in the shared variables and simultaneously sends the shared variables as telemetry packets to the ground.

[0043] Step S4 further includes:

[0044] When an onboard mission enters emergency processing, after the onboard program is updated, the main thread can terminate the emergency thread, recreate the algorithm thread, and the satellite can resume normal mission operations. See [link to relevant documentation]. Figure 5 , Figure 5 The threads shown are synchronized via signals. The arrows indicate the direction of signal transmission. External signals for the main thread include signals generated by hardware error signals, while external signals for the I / O thread include signals generated by the arrival of external data.

[0045] In summary, this invention provides an on-board software load balancing method for multi-core CPUs. It abstracts thread pools based on different functional items, ensuring that traps or faults triggered during software operation only terminate or stop a single thread, minimizing the impact on other threads. Multiple threads are dynamically allocated across multiple CPUs, balancing CPU utilization time and optimizing efficiency. The parallelism of multiple threads shortens the step size of on-board mission execution, improving the actual computational and control accuracy of the algorithm. The use of software interrupts to manage I / O port data transmission and reception ensures high real-time data processing with minimal CPU time consumption, while also overcoming the limitations of hardware interrupt quantity. The proposed shared library approach for on-orbit programming allows threads to achieve on-orbit programming simply by opening a new shared library.

[0046] Although the present invention has been described in detail through the preferred embodiments above, it should be understood that the above description should not be considered as a limitation of the present invention. Various modifications and substitutions to the present invention will be apparent to those skilled in the art after reading the above description. Therefore, the scope of protection of the present invention should be defined by the appended claims.

Claims

1. A method for on-board software load balancing of a multi-core CPU, characterized in that, Includes the following steps: S1, a thread pool is formed by abstracting the functional items of the on-board software. The thread pool includes the main thread, algorithm thread, I / O thread, remote control and telemetry thread and emergency thread. S2, the multi-core CPU has at least 4 cores, wherein the algorithm thread and I / O thread are each limited to two CPU cores, and the remaining threads are set with soft affinity and select to run on the corresponding CPU core according to the busy status of the remaining CPU cores. S3, the algorithm thread performs algorithm calculations for attitude determination, navigation, and control output. The algorithm thread, I / O thread, and remote control and telemetry thread interact with data through shared variables. Mutexes and condition variables are used to protect the shared variables and solve the problem of competition between threads. S4. When on-board software needs to be programmed in orbit, the main thread stops the corresponding thread, replaces the old shared library with the upgraded shared library, and restarts the thread; or it terminates the corresponding thread, adds the new shared library to the specified location, recreates the thread, and loads the new shared library while the thread is running. Step S3 further includes: After the algorithm thread completes the control output calculation, it sends a signal to the I / O thread. Upon receiving the signal, the I / O thread executes the output. I / O threads use signal-driven operations to satisfy data transmission and reception of multiple I / O ports, and can be used for master-slave communication or blind transmission communication with lower-level machines. After receiving the bet from the ground, the remote telemetry thread updates the bet count in the shared variables and simultaneously sends the shared variables as telemetry packets to the ground.

2. The on-board software load balancing method for multi-core CPUs as described in claim 1, characterized in that, In step S1, the main thread creates other threads, which can be stopped, restarted, or terminated by sending signals.

3. The on-board software load balancing method for multi-core CPUs as described in claim 2, characterized in that, During normal tasks, the main thread creates algorithm threads, I / O threads, and remote control and telemetry threads. If the main thread receives the same hardware error signal more than twice within 1 second, it sends a kill signal to kill the algorithm thread and creates an emergency thread, and the on-board mission enters emergency processing.

4. The on-board software load balancing method for multi-core CPUs as described in claim 1, characterized in that, Step S4 further includes: When an onboard mission enters an emergency phase, after the onboard program is updated, the main thread can terminate the emergency thread, recreate the algorithm thread, and the onboard system can resume normal operations.

Images