CN-121979781-A - Worst execution time path deducing method for ARINC653 operation system

CN121979781ACN 121979781 ACN121979781 ACN 121979781ACN-121979781-A

Abstract

The invention provides a method for deducing a worst execution time path of an ARINC653 operating system, which comprises the steps of only reserving a task to be tested in a partition to be tested, inserting piles from top to bottom from a task to be tested inlet, running the task to be tested under a target machine, injecting test case sets into the task to be tested, collecting time information of each branch in all pile points, subtracting the execution time of the pile points from the execution time of the task to be tested, obtaining a theoretical worst path and an actual worst path of a project to be tested, and running a fitting path obtained by fitting bifurcation points of the two paths under the target machine again to obtain a final WCET path. The method solves the problems that the static analysis method is difficult to meet the time allowance resource requirement of the embedded software operation, and the dynamic measurement method is difficult to prove that the obtained result is a real WCET value and the algorithm threshold is too high.

Inventors

LI RUIJUN
XUE BO
CHENG YUANQI
Tian bei
WEI YANGYANG

Assignees

中国航空工业集团公司西安飞行自动控制研究所

Dates

Publication Date: 20260505
Application Date: 20251224

Claims (10)

1. A method of worst-case execution time path derivation for an ARINC653 operating system, the method comprising: Dividing a task to be analyzed into a project to be tested with only two partitions, wherein the partitions running the project to be tested under the dispatching of an operating system are respectively a partition to be tested and a maintenance partition, and the partition to be tested only reserves the task to be tested and is used for applying excitation, monitoring and sending data to a host computer to the task to be tested in the partition to be tested; Step 2, beginning to top from the entry of the task to be tested, inserting piles from the beginning to the end of each branch which possibly affects the trend of the program in the task to be tested, wherein the pile inserting information comprises the time information of the program running to the pile point, compiling and linking the time information to generate a target code of the partition to be tested; Step 3, operating the target code of the partition to be tested in a target machine environment, injecting a test case set which is prepared in advance and can reach a percentage of coverage rate of the task to be tested into the task to be tested in the partition to be tested through a maintenance partition, and sending time information of all branches collected in all pile points to an upper computer for path analysis, wherein the coverage rate of the branches of the task to be tested is a collection result of the task to be tested from top to bottom, the collection result comprises time information of the first execution of the partition to be tested, and the time information is repeated for at least ten times, so that time operation contingency caused by single execution is eliminated; step 4, subtracting the execution time of the pile point from the execution time of the task to be detected so as to eliminate errors caused by pile point operation in the task to be detected; And 5, recording execution time of each branch in the task to be tested through pile point operation, deducing to obtain a theoretical worst path and an actual worst path of the project to be tested, fitting bifurcation points existing in each branch in the operation of the two paths through a supplement case and a manual correction mode to form a fitting path, and carrying out steps 3 to 5 on the fitting path again to finally obtain a unique and truly activatable worst execution time WCET path and a group of test case sets capable of activating the WCET path after screening.
2. The method according to claim 1, wherein the operating system adopted by the project to be tested is an embedded real-time operating system meeting the ARINC653 specification, the embedded real-time operating system uses partitions as a scheduling unit, a plurality of processes can be run in the partitions, each partition running time sequence is configured in a form of a scheduling table, and the task to be tested is configured as a non-real-time task in the project to be tested, so that faults caused by overtime of running time of the real-time task are avoided, and the task to be tested can be ensured to normally run from an inlet to an outlet.
3. The method of claim 2, wherein the partition to be tested only reserves all time windows in the exclusive schedule of the task to be tested, and is characterized in that after the task to be tested is executed with piles, the execution time of the task to be tested needs to span a plurality of time slices, if the task to be tested is switched to the next partition by the operating system when the task to be tested is not executed, the time for obtaining the piles is discontinuous, and therefore, by giving the exclusive schedule of the task to be tested, all time windows in the exclusive schedule of the task to be tested are formed, so that the task to be tested is guaranteed to be continuously operated until the work task of the partition to be tested is completed by only one partition to be tested.
4. The method according to claim 1, wherein in step 2, And respectively performing head-to-tail pile insertion on each branch which possibly affects the program trend in the task to be tested, wherein the branches comprise, but are not limited to, if/else branches and switch/case branches, and the while and for loops are added for variable-length loops.
5. The method according to claim 1, wherein in the step 3, The test cases in the test case set prepared in advance simultaneously meet the following conditions: 1) The test cases are designed based on the high-level requirements of software; 2) The branch coverage rate collection mode of the task to be tested is that the task to be tested is collected from top to bottom, cannot be pieced together from bottom to top, requires coverage rate to reach or be close to hundred percent, and all branches which cannot be covered are subjected to manual review or analysis, so that reasonable explanation is realized; 3) The worst execution time path deducing method is a performance verification range, and the test case set irrigates all branches to the test case set without ensuring the correctness of the execution function.
6. The method of claim 1, wherein the step of determining the position of the substrate comprises, The task to be tested carries out the task with piles, and the time is recorded by injecting each pile point into the program, and the eliminating mode of the pile point execution time in the step 4 comprises the following steps: continuously operating the pile points for hundreds of times, taking the single operation minimum time of the pile points, and after recording the operation time of each branch, subtracting the single operation minimum time of the pile points from the operation time of the corresponding branch so as to eliminate errors caused by each pile point; The pile points cannot be operated in a circulating mode, and the pile points must be operated in a continuous execution mode to eliminate the influence of the cache hit rate on the pile point execution efficiency.
7. The method of claim 6, wherein the step of providing the first layer comprises, In order to ensure the minimization of the stub run time, the stub obtains an efficient way of program run time by directly accessing the timer register value obtained after the bottom layer frequency division to maximize the time saving space provided by the interface of the ARINC653 operating system.
8. The method of claim 1, wherein for time fluctuation effects caused by Cache switch, cache hit rate, processor instruction pipeline factors in the project under test, the method further comprises: Each branch time is recorded from the power on, the branch execution time influenced by a Cache switch, a Cache hit rate and a processor instruction pipeline is recorded in a theoretical worst path, the historical worst execution time of each branch operation is recorded in the theoretical worst path, and the influenced branch is manually corrected to eliminate the influence caused by hardware factors.
9. The method according to claim 1, wherein after deriving the theoretical worst path and the actually measured worst path, in the step 5, there are two cases of making the paths diverge, which are respectively: In the case 1, the actually measured worst path is not matched with the theoretical worst path, and a branch of the theoretical worst path is triggered by optimizing a use case for activating the actually measured worst path, namely, a bifurcation point of the actually measured worst path is fitted to the theoretical worst path; In case 2, the theoretical worst path and the actually measured worst path are not matched, and there may be various reasons, if the branch combination of the theoretical worst path cannot be activated in any scene by manually correcting the theoretical worst path, the bifurcation point of the theoretical worst path is fitted into the actually measured worst path.
10. The method according to any one of claim 1 to 9, wherein, Slicing the engineering to be tested, namely slicing the engineering to be tested at a position with lower logic coupling degree, and executing steps 2 to 5 on each sliced engineering obtained by slicing; After the worst path of each block project is analyzed, judging whether the worst path of each block project can be activated by the same test case set, if not, re-slicing the project to be tested to obtain the worst path of each block project which can be activated by the same test case set; If yes, splicing the worst paths of each block project which can be activated by the same test case set to form the WCET path of the project to be tested.

Description

Worst execution time path deducing method for ARINC653 operation system Technical Field The invention relates to the technical field of civil aircraft embedded software verification, in particular to a worst execution time path deducing method facing an ARINC653 operating system. Background In modern civil aircraft design, on-board software bears safety key functions such as flight control, navigation, communication and the like. With the increase of software complexity (such as the wide application of integrated modular avionics system IMA), ensuring that the time sequence behavior of software in the worst case meets one of the core requirements expected to become software airworthiness certification. DO-178C, an airworthiness authentication consideration of on-board system software, is an internationally recognized civil aircraft software suitability standard, and explicitly requires analysis of the time characteristics of the security level DAL-A, DAL-B, DAL-C software (DO-178C 6.3.4f), while worst-case execution time (WCET, worst-Case Execution Time) analysis is a key means of verifying real-time constraints. The ARINC653 standard is a key operating system standard for avionics applications, and the starting point for its design concept is to provide a highly integrated, safe and reliable operating environment with predictability for avionics systems. Based on the partitioning concept, multiple applications are allowed to run simultaneously on the same physical hardware platform. Each partition is scheduled according to a certain period, no priority is assigned between the partitions, and a scheduling framework with a fixed time length is maintained by an operating system. At present, the civil aircraft software airworthiness field mainly comprises an analysis method based on static analysis and dynamic measurement. The analysis result of the static analysis method is generally larger than the real WCET value, the safety is high but pessimistic, namely the WCET value obtained by analysis is difficult to meet the time allowance resource requirement of the embedded software operation, the traditional dynamic measurement can obtain a measurement result with high credibility when an operation example is good enough, but depending on the operation example, all the inputs cannot be exhausted, the obtained result is difficult to prove to be the real WCET value, and the threshold is too high. Disclosure of Invention Aiming at the technical problems, the invention provides a worst execution time path deducing method for an ARINC653 operation system, so as to solve the problems that the existing WCET analysis method for civil engineering software airworthiness is high in safety, but the obtained WCET value is difficult to meet the time allowance resource requirement of embedded software operation, and the dynamic measurement method is difficult to prove that the obtained result is a real WCET value and the algorithm threshold is too high because all the input cannot be exhausted due to the fact that the dynamic measurement method depends on the selected operation example. The invention provides a worst execution time path deducing method facing an ARINC653 operation system, which comprises the following steps: Dividing a task to be analyzed into a project to be tested with only two partitions, wherein the partitions running the project to be tested under the dispatching of an operating system are respectively a partition to be tested and a maintenance partition, and the partition to be tested only reserves the task to be tested and is used for applying excitation, monitoring and sending data to a host computer to the task to be tested in the partition to be tested; Step 2, beginning to top from the entry of the task to be tested, inserting piles from the beginning to the end of each branch which possibly affects the trend of the program in the task to be tested, wherein the pile inserting information comprises the time information of the program running to the pile point, compiling and linking the time information to generate a target code of the partition to be tested; Step 3, operating the target code of the partition to be tested in a target machine environment, injecting a test case set which is prepared in advance and can reach a percentage of coverage rate of the task to be tested into the task to be tested in the partition to be tested through a maintenance partition, and sending time information of all branches collected in all pile points to an upper computer for path analysis, wherein the coverage rate of the branches of the task to be tested is a collection result of the task to be tested from top to bottom, the collection result comprises time information of the first execution of the partition to be tested, and the time information is repeated for at least ten times, so that time operation contingency caused by single execution is eliminated; step 4, subtracting the execution time of the pile point f