Redundant flight control software timing design method for strong and weak real-time tasks working together

Abstract

The present invention discloses a redundant flight control software timing design method for the collaborative work of strong and weak real-time tasks, comprising real-time task division, strong and weak real-time task interface design, inter-channel synchronization design, and weak real-time task timeout protection design. The method solves the problem that existing hardware resources cannot support flight control software function upgrades, and achieves capability enhancement of flight safety-critical software without changing hardware resources. Flight practice has proven that the method is economical and feasible, and can be easily applied to high-security redundant flight control software, thereby ensuring the time security of the flight control software while improving its capability.

Description

Technical Field

[0001] The present invention relates to the technical field of aircraft digital control, and in particular to a redundant flight control software timing design method for coordinated operation of strong and weak real-time tasks. Background Art

[0002] Flight control software is critical to flight safety and is a redundant, embedded, real-time software program with strict requirements for mission execution time and failure impact. In terms of real-time performance, flight control software requires a deterministic execution schedule. Its operating mechanism utilizes periodic interrupt signals to drive the periodic scheduling of various task groups, enabling each task group to execute at different intervals based on its urgency. To enhance system fault tolerance and reliability, flight control systems typically utilize redundant computers. Each redundant channel is also called a channel, and channels monitor, vote, and back up each other.

[0003] As flight control software capabilities increase, the time required for newly added functional modules increases exponentially, shrinking the time safety margin for real-time tasks and becoming a potential software safety issue. To address this issue, the current approach typically involves replacing the flight control computer's CPU with a higher-performance CPU for flight control calculations. However, hardware replacement is costly, time-consuming, and requires significant human and material resources. Summary of the Invention

[0004] The purpose of the present invention is to provide a redundant flight control software timing design method for the collaborative work of strong and weak real-time tasks, redesign the timing of the flight control software, further refine the real-time tasks, and achieve the improvement of the flight control software's capabilities while meeting the real-time requirements of the software.

[0005] In order to achieve the above tasks, the present invention adopts the following technical solutions:

[0006] A redundant flight control software timing design method for the coordinated operation of strong and weak real-time tasks, comprising:

[0007] For the newly added function module X in the flight control software, its real-time characteristics are first analyzed. If it meets the real-time requirements, it is directly classified as a real-time task.

[0008] Determine whether any intermediate calculation results of function module X during its execution need to be completed within a macroframe period and cannot be interrupted by other tasks. If so, the portion of function module X used to calculate the intermediate calculation result is classified as a strong real-time module, denoted as module A. The remaining portions of function module X other than module A are classified as weak real-time modules, denoted as module B.

[0009] Arrange module A divided in the previous step in the real-time task group of the original flight control software, and arrange module B in the background task group; when a bus interruption occurs, first run the real-time tasks in the real-time task group according to the priority order; if all real-time tasks are completed before the large frame period T is reached, run the non-real-time tasks in the background task group in the remaining time; if module B cannot complete the operation within the remaining time of the large frame period T, then after the large frame period T is reached, the operation of module B is interrupted, and the interruption scene is saved in the stack. After the real-time task scheduling of the next large frame period is completed, the interruption scene is restored and module B continues to be executed;

[0010] Set up a common memory for module A and module B to store interface variables between the two; analyze the task flow graph of module A to find the cross-linking relationship between modules A and B; if module A needs the final execution result of module B in the process of realizing its own function, and module B needs the intermediate calculation result of module A in the process of realizing its own function, then store the intermediate calculation result as the interface variable in the common memory;

[0011] During each scheduling process, the background task group will check whether there are interface variables required to trigger the operation of module B in the public memory. If so, module B will start executing. During the execution process, module B will obtain the interface variables required to implement its own functions from the public memory. The final execution result of module B is also placed in the public memory as an interface variable, which is used by module A to implement its own functions.

[0012] Furthermore, the method for determining whether the functional module meets the real-time requirements is:

[0013] For the newly added function module X in the flight control software, first schedule it as a real-time task and set its scheduling period to the large frame period T, where the large frame period is the longest scheduling period among all the existing function modules in the flight control software.

[0014] After adding the new functional module X, a simulated flight is conducted in the laboratory to determine whether control flow failures occur during the flight software operation. If no control flow failures occur, the design is complete. Otherwise, the actual runtime t1 of functional module X is recorded using flight parameters. If the actual runtime t1 of functional module X is greater than the large frame period T, proceed to the next step.

[0015] Furthermore, the real-time task group contains all real-time tasks of the flight control software sorted by priority, and the background task group contains all non-real-time tasks; wherein, the priority order of module A is determined according to the data flow of module A, thereby determining its sorting in the real-time task group.

[0016] Furthermore, in the public memory, if an interface variable is the intermediate calculation result of module A, the interface variable can only be rewritten by A; and the interface variable of the execution result of module B can only be rewritten by B, ensuring that the read and write status of the interface variable in the two modules are mutually exclusive.

[0017] Furthermore, for redundant flight control computers, the flight control software will run synchronously in each computer. Module A and Module B need to be executed synchronously in each computer to ensure the consistency of each redundancy result. By designing a synchronization mechanism between different computer channels, Module B in each channel can be executed synchronously.

[0018] Furthermore, the synchronization mechanism between different computer channels is specifically as follows:

[0019] After module B of this channel is executed, the calculation completion flag is assigned a value of 1;

[0020] Through the cross-transmission function between channels, the calculation completion flag of this channel is transmitted to the other two channels; when this channel obtains the calculation completion flag of the other two channels, the A module of each channel calculates the voting value. When the calculation completion flags of all channels are 1, the final voting value is assigned to 1, indicating that the B modules in each channel have been executed; when the A module of each channel receives the next bus clock interrupt, it will synchronously obtain the interface variable corresponding to the final execution result of the B module from the public memory of each channel.

[0021] Furthermore, a worst-case execution time Tmax of module B is set, and a time variable Tb is set; each time a large frame period T is executed, if module B has not yet been completed, the value of the time variable Tb is added to a large frame period T; if the current Tb exceeds the set worst-case execution time Tmax, module B is considered to have timed out, and the function of module B will not be executed.

[0022] A computer-readable storage medium stores a computer program; when the computer program is executed by a processor, the steps of a redundant flight control software timing design method for collaborative working of strong and weak real-time tasks are implemented.

[0023] Compared with the prior art, the present invention has the following technical features:

[0024] The method of the present invention solves the problem of existing hardware resources being unable to support flight control software upgrades. Without changing hardware resources, it enhances the capabilities of flight-safety-critical software. Existing public documentation lacks any description or implementation of this method. Flight practice has proven the method to be economical and feasible, and it can be easily applied to high-security, redundant flight control software. While improving the capabilities of flight control software, it also ensures its time safety. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 This is a diagram of the flight control software task scheduling sequence;

[0026] Figure 2 Schematic diagram of the relationship between functional modules and scheduling cycles;

[0027] Figure 3 This is the original timing scheduling diagram of functional module X;

[0028] Figure 4 This is a schematic diagram of the timing scheduling of the split functional modules A and B;

[0029] Figure 5 Design a schematic diagram for the timing coordination relationship between strong and weak real-time modules A and B;

[0030] Figure 6 Design a schematic diagram for the strong and weak real-time module interface;

[0031] Figure 7 Design a schematic diagram for the channel synchronization mechanism;

[0032] Figure 8 A schematic diagram showing the timing coordination relationship between strong and weak real-time tasks in an embodiment of the invention;

[0033] Figure 9 This is a schematic diagram of the interface design of the strong and weak real-time modules in the embodiment of the invention;

[0034] Figure 10 Schematic diagram of the channel synchronization mechanism in an embodiment of the invention. DETAILED DESCRIPTION

[0035] The operation of the flight control software is driven by the clock interrupt of the bus. Every time the bus clock interrupt comes, the flight control software schedules the real-time task to run according to the pre-set schedule. The time between two bus clock interrupts is called a time period △t, which is generally in milliseconds. The real-time tasks and non-real-time tasks in the flight control software are defined as: A real-time task means that the task needs to be completed within a set period, and cannot be interrupted by other tasks within the period, or can only be interrupted a few times, otherwise the software will have a timing error and report a "control flow failure", which seriously affects flight safety. The calculation results of non-real-time tasks do not affect flight safety. They run in the remaining time slice after all real-time tasks are completed. They can be interrupted at any time during their operation, and the number of interruptions is unlimited. The operation rules of real-time tasks and non-real-time tasks in flight control software are as follows. Figure 1As shown in the figure, the flight control software in this example has three real-time tasks. Real-time task 1 has the highest priority and must complete its calculation within time Δt. Its scheduling period is Δt. Similarly, the scheduling period of real-time task 2 is 2Δt, and the scheduling period of real-time task 3 is 4Δt. The longest real-time task scheduling period is 4Δt, also known as the large frame period T. Non-real-time tasks run in the remaining time slice t(r) after all real-time tasks in a large frame have completed execution.

[0036] The functional modules in the flight control software generally include signal input and output, signal voting monitoring, flight navigation calculation, aircraft control surface control, fault recording, ground maintenance, etc. According to the real-time requirements of the modules and the criticality of their impact on flight safety, these functional modules can be divided into real-time tasks and non-real-time tasks. Among them, signal input and output, signal voting monitoring, flight navigation calculation, aircraft control surface control and other functional modules have a greater impact on flight safety, have a high task priority, and are usually arranged as real-time tasks; fault recording, ground maintenance and other functional modules have a smaller impact on flight safety, have a lower priority, and are usually arranged as non-real-time tasks. The scheduling cycle of each functional module is as follows: Figure 2 shown.

[0037] This invention discloses a redundant flight control software timing design method for the coordinated operation of strong and weak real-time tasks. This method aims to design the timing for all newly added functional modules in the current flight control software. This method improves the flight control software's ability to handle complex tasks, enhances its security, and addresses the issue of existing hardware resources being unable to support flight control software function upgrades.

[0038] Referring to the accompanying drawings, the steps of this method are as follows:

[0039] Step 1: For the newly added functional module X in the flight control software, first analyze its real-time characteristics. If it meets the real-time requirements, directly classify it as a real-time task; otherwise, proceed to the next step.

[0040] The method to determine whether the functional module meets the real-time requirements is:

[0041] Assume that a new function module X is added to the flight control software. First, it is scheduled as a real-time task and the scheduling period of the function module is set to the large frame period T of the original function module of the flight control software. For example, Figure 3 As shown in the figure, the large frame period refers to the longest scheduling period among all the original functional modules of the flight control software.

[0042] After adding the new functional module X, a simulated flight is conducted in the laboratory to determine whether a control flow failure occurs during the flight software's operation. If no control flow failure occurs, the design is complete. Otherwise, the runtime of functional module X exceeds the large frame period T of the software's real-time task. The actual runtime time t1 of functional module X is recorded using flight parameters. If the actual runtime time t1 of functional module X exceeds the large frame period T, it indicates that the module will be in an unfinished state when it is next scheduled (time 2T), causing a "control flow failure." The next step is then carried out.

[0043] Step 2: Determine whether any intermediate calculation results of function module X during its execution need to be completed within a macroframe period and cannot be interrupted by other tasks. If so, the portion of function module X used to calculate the intermediate calculation result is classified as a strong real-time module, denoted as module A. The remaining portions of function module X other than module A are classified as weak real-time modules, denoted as module B.

[0044] like Figure 2 In the example given, a portion of the calculation results of the newly added functional module X must be transmitted in real time to the flight navigation module for use. This portion must complete within a macroframe period and cannot be interrupted by other tasks. Therefore, it is classified as a strong real-time module (module A). The other portion performs only arithmetic operations and can be interrupted at will by other tasks. It only needs to provide calculation results within a specified time (a time greater than the macroframe period T, such as 5T). However, the characteristics of this portion are different from those of non-real-time tasks. Its calculation results have a certain impact on flight safety, and the calculation completion time cannot be extended indefinitely. Therefore, the real-time and safety requirements of this portion are between those of strong real-time and non-real-time tasks. Here, it is defined as a weak real-time module (module B).

[0045] Step 3, the strong real-time module (module A) divided in the previous step is arranged in the real-time task group of the original flight control software, and the weak real-time module (module B) is arranged in the background task group; the real-time task group is all real-time tasks of the flight control software according to the priority sorting, and the background task group is all non-real-time tasks;

[0046] The priority order of module A is determined according to its data flow, thereby determining its order in the real-time task group. When a bus interrupt occurs, the real-time tasks in the real-time task group are first run according to the priority order. If all real-time tasks have been completed but the large frame period T has not been reached, the non-real-time tasks in the background task group are run in the remaining time.

[0047] If the module B cannot complete its operation within the remaining time of the large frame period T, the operation of the module B will be interrupted after the large frame period T is reached, and the interruption scene will be saved to the stack. After the real-time task scheduling of the next large frame period is completed, the interruption scene will be restored and the execution of the module B will continue. The same method will be used to pass through several large frame periods until the module B is completely executed.

[0048] In one example of the present invention, the timing design of the entire flight control software is as follows: Figure 4 As shown in the figure, when a bus interrupt occurs at time Δt, the real-time tasks in the real-time task group are run according to their priority. In this example, the data input / output module, with the highest priority, runs first, followed by module A. The result calculated by module A is passed to the flight navigation module, which then runs. When a bus interrupt occurs at time 3Δt, the data input / output module runs first. At this point, all real-time tasks within a large frame cycle have completed. The software returns to the background task and begins executing background non-real-time tasks. At this time, the weak real-time task module B begins to run. Due to its long computation time, it cannot complete its calculation within the remaining time slice t(r). When a bus interrupt occurs at time 4Δt (time T), module B's execution is interrupted. The software automatically saves the interruption scene to the stack and begins scheduling real-time tasks for the next large frame cycle. After all real-time tasks in the next large frame cycle have completed their calculations, the software returns to the background task again, automatically restoring the scene from the previous interruption, and module B resumes execution from the point where it was interrupted. After several large frame cycles, module B completes its calculations.

[0049] Step 4: Design the coordination and interface relationship between the strong real-time module and the weak real-time module.

[0050] Set up a common memory for module A and module B to store the interface variables between them. Analyze the task flow graph of module A and find the cross-link relationship between modules A and B. If module A needs the final execution result of module B in the process of implementing its own function, and module B needs the intermediate calculation results of module A in the process of implementing its own function, then:

[0051] An intermediate calculation result of module A is the data required to trigger module B to start running or module B to realize its function, and it is stored in the public memory as an interface variable;

[0052] During each scheduling process, the background task group will check whether there is an interface variable in the public memory required to trigger the operation of module B. If the interface variable exists, module B will start executing. During the execution process, module B will obtain the interface variables required to implement its own functions from the public memory. The final execution result of module B is also placed in the public memory as an interface variable, which is used by module A to implement its own functions.

[0053] Furthermore, in the public memory, if an interface variable is the intermediate calculation result of module A, the interface variable can only be rewritten by A; and the interface variable of the execution result of module B can only be rewritten by B, ensuring that the read and write status of the interface variable in the two modules are mutually exclusive, avoiding confusion in the software status caused by the interface variable being cross-rewritten by the two modules.

[0054] In the example given in the attached figure, since a functional module X is split into a real-time task group and a background task group, it is necessary to design the coordination relationship between module A and module B to realize the complete function. In order to describe the coordination relationship between the two, other tasks are ignored and only the operation of module A and module B is focused. Figure 5 As shown, within a large frame cycle, Module A executes first. Module A prepares some data as input for Module B, calculates a startup flag, FLAGA, and stores it in memory as an interface variable. When Module B enters the background task, if Module B reads the flag FLAGA as "true," it triggers its internal complex mathematical operations to calculate the navigation data required by Module A. Within several large frame cycles, if Module B completes the calculation, it stores the result, DATAOUT, in memory and generates a flag, FLAGB. If Module A reads the flag as "true," it reads DATAOUT and refreshes it in real time for the navigation module to use.

[0055] Module A and module B need to exchange data. These data are the interface variables between the two modules. In this example, the data flow between the two modules is as follows: Figure 6 When designing software, it is important to note that DATAIN and FLAGA can only be rewritten in module A, and module B can only read their contents but not rewrite their values. Conversely, DATAOUT and FLAGB can only be rewritten in module B, and module A can only read their contents but not rewrite their values.

[0056] Step 5: For redundant flight control computers, the flight control software will run synchronously in each computer. That is, module A and module B need to be executed synchronously in each computer to ensure the consistency of the redundancy results. The synchronization of module A can be triggered by bus clock interrupt synchronization. However, due to the influence of different hardware devices and software states, the scheduling status of module B in the background task groups of multiple computer channels may not be completely consistent. Therefore, by designing a synchronization mechanism between different computer channels, module B in each channel can be executed synchronously:

[0057] The specific method used is to conduct handshake voting between channels, such as Figure 7 As shown in the figure, after module B of this channel is executed, the calculation completion flag FLAGB_CHX is assigned a value of 1;

[0058] Through the cross-channel transmission function CCDL, the calculation completion flag of this channel is transmitted to the other two channels, so that one channel obtains the status of three channels; when this channel obtains the calculation completion flag of the other two channels, the A module of each channel calculates the voting value. When the calculation completion flags of all channels are 1, the final voting value is assigned to 1, indicating that the B modules in each channel have been executed; when the A modules of each channel receive the next bus clock interrupt, they will synchronously obtain the interface variables corresponding to the final execution results of the B modules from the public memory of each channel.

[0059] The background introduction clarified that to improve system fault tolerance and reliability, flight control computers typically employ a redundant design. Each redundant channel is also called a channel. Channels monitor, vote, and back up each other. This example uses a triple-redundant flight control computer. The CPU boards of the three channels are connected to the same system bus and receive the same bus interrupts. Therefore, the scheduling times of the real-time tasks of the three channels are consistent and deterministic. However, due to variations in CPU execution speed, external devices, and input data, the scheduling status of background tasks across the three channels is inconsistent. This does not affect traditional non-real-time tasks, but it is unacceptable for module B, which has weak real-time requirements.

[0060] If module B on one channel completes its calculations while another channel hasn't, the execution timing of real-time module A on the three channels will be inconsistent, disrupting the overall software timing and causing serious software issues. Therefore, it's necessary to design an inter-channel synchronization mechanism for module B to ensure that module B completes on all channels before triggering module A.

[0061] In this example, channel X calculates the final voting value, FLAGB_VOTE, based on its own flags (FLAGB_CHX, FLAGB_CHY, and FLAGB_CHZ) and the other two channels. The voting logic is as follows: It determines whether all channel flags are true. If so, the voting value, FLAGB_VOTE, is set to true. Otherwise, if any channel flag is false, the voting value, FLAGB_VOTE, is set to false. A true voting value, FLAGB_VOTE, indicates that calculations for module B are complete for all channels. This ensures that the triggering timing of real-time module A is consistent across all three channels, guaranteeing synchronization of software timing states between channels.

[0062] Step 6: Design a timeout protection mechanism for weak real-time tasks.

[0063] Based on the characteristics of module B, a worst-case execution time Tmax is set for module B, and a time variable Tb is also set. Each time a large frame cycle is executed, if module B has not yet completed execution, the value of the time variable Tb is added to the large frame cycle T. If the current Tb exceeds the set worst-case execution time Tmax, module B is considered to have timed out, and its function is not executed to prevent the fault from spreading and affecting flight safety.

[0064] The real-time and safety requirements of weak real-time tasks are between those of strong real-time tasks and non-real-time tasks. Non-real-time tasks have no timeliness requirements and no restrictions on entry, exit, and running time. However, weak real-time tasks have certain timeliness requirements. The calculation results of module B need to be completed within several limited large frame periods, otherwise it will affect subsequent navigation functions. Therefore, it is necessary to design a timeout protection mechanism for weak real-time tasks.

[0065] The above design and development are simulated and verified.

[0066] The flight control software was redeveloped according to the above design and simulated in the laboratory. The software no longer reported "control flow failure" errors during operation. Using the test equipment to check flight parameters, the runtime of functional module A, t(a), and functional module B, t(b), were determined. Analysis revealed that t(a) < the large frame period, T, and t(b) ≈ 5T. This indicates that functional module A meets the requirements for the real-time task scheduling period, while functional module B meets the requirements for weak real-time tasks. This validates the accuracy and feasibility of the above analysis and design.

[0067] Example:

[0068] A certain drone flight control software needs to add a dynamic route planning function with an "electronic fence", where the "electronic fence" is a closed and non-self-intersecting figure formed by connecting a series of coordinate points on the map in a clockwise or counterclockwise direction; route planning with an "electronic fence" means that when the drone encounters an "electronic fence" while flying according to the predetermined route, it needs to recalculate the route to avoid the aircraft flying into or out of the "electronic fence", which is hereinafter referred to as the electronic fence function. The time required to complete the calculation of the electronic fence function is much longer than the scheduling period of the real-time task. If it is scheduled to be completed in the real-time task, the "flight navigation" real-time task will not be calculated and completed within the specified period, resulting in a software timing error. Therefore, this method is used to redesign the timing of the electronic fence function. The specific steps are as follows:

[0069] (1) The electronic fence function is divided into two modules according to the strength of real-time, namely the logic calculation module (strong real-time) and the route planning module (weak real-time).

[0070] (2) The logic calculation module takes time at the microsecond level, and its calculation results need to be refreshed every cycle. It has the characteristics of a strong real-time task, so it is arranged in the real-time task group; the logic calculation module decides whether to start route planning based on the current position of the aircraft and the instructions of the ground station, and transmits the calculation results of the route planning to the flight navigation module in real time.

[0071] (3) The route planning module takes only seconds and does not require refreshing the calculation results every cycle. It has the characteristics of a weak real-time task, so it is arranged in the background task group. The route planning module performs route planning through complex arithmetic operations and only needs to provide the calculation results within a specified time (a time greater than the large frame period T).

[0072] (5) Design the timing coordination relationship between the logic calculation module and the route planning module, such as Figure 8 As shown in the figure, the software first enters the real-time task to perform logical calculations for the geo-fence function. Within a large frame cycle, there is always remaining time after the real-time task completes. During this remaining time, the software enters the background task and begins route planning for the geo-fence function. Because route planning takes longer than the interrupt cycle, the next interrupt interrupt interrupts the route planning task, saves the interruption scene, and enters the real-time task to perform logical calculations. After completing the logical calculations, the software returns to the background task to perform route planning, restores the scene of the previous interruption, and continues from the interruption point. After several interrupt cycles, when route planning is complete, the real-time task is notified and the final calculation results (the planned route chain) are transmitted.

[0073] (4) Design the interface between modules, such as Figure 9 As shown in the figure, the electronic fence coordinate data, airport coordinates, and aircraft coordinates are the inputs transmitted by the logic calculation module to the route planning module. The planned route chain and route planning completion flag are the results calculated by the route planning module. These variables all meet the requirement of mutually exclusive states in the two modules, that is, if a variable is writable in the strong real-time module, it is read-only in the weak real-time module, and vice versa.

[0074] (6) Design inter-channel synchronization mechanism, such as Figure 10As shown in the figure. Since the execution time of background tasks for each channel is uncertain, it is possible that the route planning for one channel is completed while the route planning for another channel is not. If handshake voting is not performed between channels, it may cause the real-time task to misbehave, which in turn causes the entire software timing to be disrupted, leading to serious software problems. Therefore, it is necessary to design a synchronization mechanism between channels to ensure consistent software behavior in each channel. The method used is to generate a route planning completion flag after the route planning of each channel is completed, and cross-transmit it between channels to determine whether all channels have been planned. If so, all channel planning completion flags and route planning results are transmitted to the real-time task. Otherwise, the route planning results are not transmitted.

[0075] (7) Design a timeout protection mechanism for weak real-time tasks. The difference between weak real-time tasks and non-real-time tasks is that non-real-time tasks have no time limit requirements, while weak real-time tasks have certain time limit requirements. The route chain calculated by route planning needs to be passed to the real-time task to navigate the aircraft. The calculation must be completed within a certain time. Otherwise, the route planning timeout flag is set, indicating that there is a problem with the function and shutting down the function to prevent the fault from spreading and affecting flight safety.

[0076] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A redundant flight control software timing design method for the coordinated operation of strong and weak real-time tasks, characterized by: include: For the newly added function module X in the flight control software, its real-time characteristics are first analyzed. If it meets the real-time requirements, it is directly classified as a real-time task. Determine whether any intermediate calculation results of function module X during its execution need to be completed within a macroframe period and cannot be interrupted by other tasks. If so, the portion of function module X used to calculate the intermediate calculation result is classified as a strong real-time module, denoted as module A. The remaining portions of function module X other than module A are classified as weak real-time modules, denoted as module B. Arrange module A divided in the previous step into the real-time task group of the original flight control software, and module B into the background task group; When a bus interrupt occurs, the real-time tasks in the real-time task group are first run in order of priority; if all real-time tasks are completed but the large frame period T has not been reached, the non-real-time tasks in the background task group are run in the remaining time; if the module B cannot complete the operation within the remaining time of the large frame period T, the operation of the module B is interrupted after the large frame period T is reached, and the interruption scene is saved in the stack. After the real-time task scheduling of the next large frame period is completed, the interruption scene is restored and the execution of the module B continues; Set up a common memory for module A and module B to store interface variables between the two; analyze the task flow graph of module A to find the cross-linking relationship between modules A and B; if module A needs the final execution result of module B in the process of realizing its own function, and module B needs the intermediate calculation result of module A in the process of realizing its own function, then store the intermediate calculation result as the interface variable in the common memory; During each scheduling process, the background task group will check whether there is an interface variable in the public memory required to trigger the execution of module B. If so, module B will start executing; During the execution process, module B will obtain the interface variables required to implement its own functions from the public memory; the final execution result of module B is also placed in the public memory as an interface variable, which is used by module A to implement its own functions.

2. The redundant flight control software timing design method for strong and weak real-time task collaboration according to claim 1 is characterized in that: The method to determine whether the functional module meets the real-time requirements is: For the newly added function module X in the flight control software, first schedule it as a real-time task and set its scheduling period to the large frame period T, where the large frame period is the longest scheduling period among all the existing function modules in the flight control software. After adding the new functional module X, a simulated flight is conducted in the laboratory to determine whether control flow failures occur during the operation of the flight software; If it does not exist, the design is complete; Otherwise, the actual running time t1 of the functional module X is recorded using the flight parameters. If the actual running time t1 of the functional module X is greater than the large frame period T, proceed to the next step.

3. The redundant flight control software timing design method for strong and weak real-time task collaboration according to claim 1 is characterized in that: The real-time task group contains all real-time tasks of the flight control software sorted by priority, and the background task group contains all non-real-time tasks; wherein, the priority order of module A is determined according to the data flow of module A, thereby determining its sorting in the real-time task group.

4. The redundant flight control software timing design method for strong and weak real-time task collaboration according to claim 1 is characterized in that: In the public memory, if an interface variable is the intermediate calculation result of module A, the interface variable can only be rewritten by A; and the interface variable of the execution result of module B can only be rewritten by B, ensuring that the read and write status of the interface variable in the two modules are mutually exclusive.

5. The redundant flight control software timing design method for strong and weak real-time task collaboration according to claim 1 is characterized in that: For redundant flight control computers, the flight control software will run synchronously in each computer. Module A and Module B need to be executed synchronously in each computer to ensure the consistency of the redundancy results. By designing a synchronization mechanism between different computer channels, Module B in each channel can be executed synchronously.

6. The redundant flight control software timing design method for strong and weak real-time task collaboration according to claim 5 is characterized in that: The synchronization mechanism between different computer channels is specifically as follows: After module B of this channel is executed, the calculation completion flag is assigned a value of 1; Through the cross-transmission function between channels, the calculation completion flag of this channel is transmitted to the other two channels; when this channel obtains the calculation completion flag of the other two channels, the A module of each channel calculates the voting value. When the calculation completion flags of all channels are 1, the final voting value is assigned to 1, indicating that the B modules in each channel have been executed; when the A module of each channel receives the next bus clock interrupt, it will synchronously obtain the interface variable corresponding to the final execution result of the B module from the public memory of each channel.

7. The redundant flight control software timing design method for strong and weak real-time task collaboration according to claim 1 is characterized in that: Set a worst-case execution time Tmax for module B and set a time variable Tb. Each time a large frame period T is executed, if module B has not yet completed execution, the value of the time variable Tb is added to the large frame period T. If the current Tb exceeds the set worst-case execution time Tmax, module B is considered to have timed out and the function of module B will not be executed.

8. A computer-readable storage medium storing a computer program; wherein: When the computer program is executed by a processor, the steps of the redundant flight control software timing design method for the coordinated operation of strong and weak real-time tasks according to any one of claims 1 to 7 are implemented.

Images