Method for deducing worst execution time path for ARINC653 operating system

Abstract

The invention provides a worst execution time path derivation method for an ARINC653 operating system. Only tasks to be tested are reserved in a partition to be tested; from the entrance of the to-be-tested task to top down, performing pile pitching on each branch possibly influencing the program trend in the to-be-tested task; running the to-be-tested task under the target machine, injecting a test case set into the to-be-tested task, and collecting time information of each branch in all pile points; subtracting the execution time of the pile point from the execution time of the to-be-tested task; and obtaining a theoretical worst path and an actual worst path of the to-be-tested project, fitting the bifurcation points of the two paths to obtain a fitting path, running the fitting path under the target machine again, and obtaining a final WCET path. The method solves the problems that a static analysis method is difficult to meet the time margin resource requirement of embedded software operation, a dynamic measurement method is difficult to prove that the obtained result is a real WCET value, and the algorithm threshold is too high.

Description

Technical Field

[0001] This invention relates to, but is not limited to, the field of embedded software verification technology for civil aircraft, and particularly to a method for deriving the worst execution time path for the ARINC653 operating system. Background Technology

[0002] In modern civil aircraft design, airborne software undertakes safety-critical functions such as flight control, navigation, and communication. With increasing software complexity (such as the widespread application of Integrated Modular Avionics Systems (IMAs), ensuring that the software's timing behavior meets expectations under worst-case conditions has become one of the core requirements for airworthiness certification. DO-178C, "Airborne System Software Airworthiness Certification Considerations," as an internationally recognized standard for civil aircraft software suitability, explicitly requires the analysis of the timing characteristics of software with safety levels DAL-A, DAL-B, and DAL-C (DO-178C 6.3.4f), and worst-case execution time (WCET) analysis is a key means of verifying real-time constraints.

[0003] The ARINC 653 standard, a key operating system standard for avionics systems, is designed to provide a highly integrated, secure, reliable, and predictable operating environment for avionics systems. Based on the concept of partitioning, it allows multiple applications to run simultaneously on the same physical hardware platform. Each partition is scheduled according to a defined cycle, with no priority between partitions; the operating system maintains a fixed-time scheduling framework.

[0004] Currently, the airworthiness of civil aircraft software mainly employs analysis methods based on static analysis and dynamic measurement. Static analysis generally yields results greater than the actual WCET value, offering high security but also a pessimistic outlook; that is, the obtained WCET value may not meet the time margin requirements of embedded software operation. Traditional dynamic measurement can provide highly reliable results when the running instances are sufficiently good, but it relies on selecting specific running instances. Because it's impossible to exhaustively list all inputs, it's difficult to prove that the obtained result is the true WCET value, making the threshold too high. Summary of the Invention

[0005] The purpose of this invention is to address the aforementioned technical problems by providing a worst-case execution time path derivation method for the ARINC653 operating system. This method solves the problems of existing WCET analysis methods used in civil aircraft software airworthiness testing, which have high security but whose obtained WCET values ​​are difficult to meet the time margin resource requirements of embedded software operation. Furthermore, dynamic measurement methods rely on selected running instances, making it difficult to prove that the obtained results are true WCET values ​​due to the inability to exhaustively enumerate all inputs, and also have too high an algorithm threshold.

[0006] The technical effect of this invention is as follows: This invention provides a method for deriving the worst execution time path for the ARINC653 operating system, the method comprising: Step 1: Divide the task to be analyzed into a test project with only two partitions. The partitions of the test project that run under the scheduling of the operating system are the test partition and the maintenance partition. The test partition only retains the test task and is used to apply stimuli, monitor and send data to the host computer for the test task in the test partition. Step 2: Starting from the entry point of the task under test, work from top to bottom, and instrument each branch in the task under test that may affect the program's direction. The instrumentation information includes the time information of the program running to the instrumentation point. After compilation and linking, the target code of the partition under test is generated. Step 3: Run the target code of the partition under test in the target machine environment. Inject a pre-prepared set of test cases with 100% coverage of the task under test into the task under test in the partition under test through the maintenance partition. Send the time information of each branch collected from all stubs to the host computer for path analysis. The branch coverage of the task under test is the collection result of the task under test from top to bottom. The collection result includes the time information of the first execution of the partition under test, and is repeated at least ten times to eliminate the time randomness caused by a single execution. Step 4: Subtract the execution time of the piling points from the execution time of the task under test to eliminate the error caused by the piling point operation in the task under test; Step 5: By recording the execution time of each branch in the task under test through the piling point operation record, the theoretical worst path and the actual worst path of the project under test are derived. The two paths are fitted to the bifurcation points of each branch in the two paths through supplementary test cases and manual correction to form a fitted path. Steps 3 to 5 are repeated on the fitted path to finally obtain a unique, real worst execution time WCET path that can be activated, as well as a set of test cases that can be activated after screening.

[0007] Optionally, in the method described above, the operating system used in the project under test is an embedded real-time operating system that meets the requirements of the ARINC653 specification. The embedded real-time operating system uses partitions as scheduling units, and several processes can run within a partition. The runtime sequence of each partition is configured in the form of a scheduling table. In the project under test, the task under test is configured as a non-real-time task to avoid failures caused by timeouts of real-time tasks and to ensure that the task under test can run normally from the entry point to the exit point.

[0008] Optionally, in the method described above, the partition under test only retains the task under test, which means that the task under test exclusively occupies all time windows in the scheduling table. The reason for this is that after the task under test is executed with stubs, its required execution time needs to span multiple time slices. If the operating system switches to the next partition before the task under test has been completed, it may cause the time for obtaining stubs to be discontinuous (spanning the time of a maintenance partition). Therefore, by exclusively occupying all time windows in the scheduling table for the task under test, it is ensured that there is only one partition under test in the scheduling table that continues to run until the task under test is completed.

[0009] It should be noted that the execution time of the task under test with stakes means that after the stakes are inserted and the stakes are obtained, the execution time of each stake point should be added to the execution time of the task under test.

[0010] Optionally, in the method described above, step 2 includes: For each branch in the task under test that may affect the program's direction, instrument the beginning and end of the branch. The branches include, but are not limited to, if / else branches and switch / case branches. For variable-length loops, add while and for loops.

[0011] Optionally, in the method described above, in step 3, The pre-prepared test case set contains test cases that simultaneously meet the following conditions: 1) All test cases are designed based on high-level software requirements; 2) The branch coverage of the task to be tested shall be collected from top to bottom, not pieced together from bottom to top. The coverage shall reach or be close to 100%. All branches that cannot be covered shall be manually reviewed or analyzed and have a reasonable explanation. 3) The worst-case execution time path derivation method is to test all branches within the performance verification scope, without needing to guarantee the correctness of the execution function.

[0012] Optionally, in the method described above, The task to be tested is executed with staked nodes. The execution time of each staked node is recorded by injecting it into the program. The methods for eliminating the execution time of staked nodes in step 4 include: After running the pile points hundreds of times, the minimum time for a single run is taken. After recording the running time of each branch, the minimum time for a single run of the pile point is subtracted from the running time of the corresponding branch to eliminate the error caused by each pile point. The continuous execution of stubs cannot be done in a loop; stubs must be executed continuously to eliminate the impact of cache hit rate on stub execution efficiency.

[0013] Optionally, in the method described above, To minimize the runtime of the stubs, the most efficient way to obtain the program runtime is by directly accessing the value of the timer register after frequency division at the underlying level. This maximizes time-saving space, and the time is provided by the interface of the ARINC653 operating system.

[0014] Optionally, in the method described above, for the time fluctuations in the project under test caused by cache switching, cache hit rate, and processor instruction pipeline factors; the method further includes: The execution time of each branch is recorded from the moment the power is turned on. The execution time of branches affected by cache switching, cache hit rate and processor instruction pipeline is recorded in the theoretical worst path. The theoretical worst path records the worst historical execution time of each branch. The affected branches are manually corrected to eliminate the impact of hardware factors.

[0015] Optionally, in step 5 of the method described above, after deriving the theoretical worst-case path and the measured worst-case path, there are two cases where the path branches, namely: Case 1: The measured worst path does not match the theoretical worst path. By optimizing the test cases that activate the measured worst path, the branch of the theoretical worst path is triggered, that is, the branch point of the measured worst path is fitted to the theoretical worst path. Case 2: The theoretical worst path does not match the measured worst path. There may be multiple reasons for this. In this case, the theoretical worst path is manually corrected. If the branch combination of the theoretical worst path cannot be activated in any scenario, the branch point of the theoretical worst path is fitted to the measured worst path.

[0016] Optionally, in the method described above, For a large-scale project under test (e.g., a project with more than 10,000 lines of code), the project under test is sliced, that is, the project under test is divided into parts with low logical coupling, and steps 2 to 5 are executed on each of the sliced ​​parts. After analyzing the worst path of each sub-project, determine whether the worst path of each sub-project can be activated by the same set of test cases. If not, the worst path of each sub-project that can be activated by the same set of test cases is obtained by re-slicing the project under test. If so, the worst paths of each sub-project that can be activated by the same test case set are spliced ​​together to form the WCET path of the project under test.

[0017] The beneficial effects of this invention are as follows: This invention proposes a worst-case execution time (WCET) path derivation method for the ARINC653 operating system. It utilizes the ARINC653 standard operating system's partition scheduling and partition isolation mechanisms to isolate the task under test as a non-real-time task on a separate test partition. The task under test is then stimulated, monitored, and data is sent to the host computer. Through measurement, starting from the entry point of the task under test and working downwards, each branch in the task under test that may affect the program's direction is instrumented at both ends to collect the branch times that may affect the program's execution path, thereby deriving the path that may activate the worst-case execution time (WCET). The beneficial effects of the WCET path derivation method provided by this invention are: First, by utilizing the ARINC653 operating system based on mechanisms such as partition scheduling and partition isolation, the integrity of the task under test is guaranteed to the greatest extent. Second, in this embodiment of the invention, all path selection and analysis processes, as well as time measurement results, are based on the actual measured time of the target machine, so as to obtain the worst execution time WCET path in the most realistic and accurate way, and eliminate the influence of human experience factors on the analysis; compared with the purely static analysis method, the reliability of the time can be guaranteed. Third, for DAL-A, DAL-B, and DAL-C level software, the statement coverage target in DO-178C must be met. This invention combines the statement coverage collection results and goes a step further than the traditional dynamic measurement method of WCET. After obtaining the time execution status of all branches through statistical methods, it analyzes and derives them one by one, and continuously refines test cases that can activate the worst execution path, thereby maximizing the accuracy of the WCET path.

[0018] In summary, this invention provides a method for deriving the worst execution time path based on actual measurements. It is applicable to all projects under test using the ARINC653 operating system framework. By deriving step by step, a set of test cases that can activate the worst execution time is obtained, which maximizes the accuracy of the worst execution time path analysis results. Attached Figure Description

[0019] The accompanying drawings are provided to further understand the technical solutions of the present invention and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of the present invention and do not constitute a limitation on the technical solutions of the present invention.

[0020] Figure 1 This invention provides a schematic diagram of partition switching timing based on the ARINC653 operating system as an embodiment of the present invention; Figure 2 The diagram shows a flowchart of a worst-case execution time path derivation method for the ARINC653 operating system proposed in an embodiment of the present invention. Figure 3 for Figure 2 The illustrated embodiment provides an example diagram of the time analysis and path derivation process in the worst-case execution time path derivation method. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

[0022] As explained in the background section, the current airworthiness analysis methods for civil aircraft software mainly include static analysis and dynamic measurement-based methods. Static analysis does not require running the target program in an actual environment; it only estimates the WCET result closest to the actual operating conditions by modeling the characteristics of the software and hardware in the system. However, its accuracy is limited by the precision of the hardware modeling, and because it is not based on actual measurements, its analysis results are generally greater than the actual WCET value, offering high safety but also a relatively pessimistic outlook.

[0023] Traditional dynamic measurement can yield highly reliable results when the running instances are sufficiently good, and the resulting WCET data is close to reality, minimizing resource waste. However, because it relies on selecting specific running instances, performance testing of large-scale embedded code using traditional manual methods—debugging and recording execution times, calculating and evaluating average load rates—is extremely labor-intensive. Furthermore, it's impossible to cover all operating conditions, leading to difficulties in pinpointing problems and reproducing sporadic timeouts and overloads, thus reducing the reliability of the results. The inability to exhaustively enumerate all inputs makes it difficult to prove that the obtained results are true WCET values, setting the bar too high.

[0024] To address the aforementioned issues, this invention provides a worst-case execution time path derivation method for the ARINC653 operating system. This method is applicable to the worst-case execution time path derivation of all embedded software in civilian aircraft, but it performs best in practice for embedded software using the ARINC653 standard operating system.

[0025] In summary, the worst-case execution time path derivation method for the ARINC653 operating system provided by this invention, through improvements to the traditional WCET analysis method, can optimize the system WCET analysis process through statistical means while retaining the advantages of dynamic analysis. This method can more accurately derive the worst-case execution path, improve the certainty and confidence of the analysis results, thereby enhancing the persuasiveness and acceptability during airworthiness certification. This method is a general method for embedded software, but it is most suitable for projects under test using the ARINC653 standard operating system because it uses partitions as the scheduling unit. Each partition is designed as an entity that can execute independent applications, with its own address space, system resources, and execution flow. This can isolate the task under test to the greatest extent possible, achieving effective isolation of the test object.

[0026] The present invention provides the following specific embodiments, which can be combined with each other. For the same or similar concepts or processes, they may not be described again in some embodiments.

[0027] like Figure 2 The diagram shows a flowchart of a worst-case execution time path derivation method for the ARINC653 operating system proposed in an embodiment of the present invention. The worst-case execution time path derivation method for the ARINC653 operating system provided by the present invention includes the following steps: Step 1: Divide the task to be analyzed into a test project with only two partitions. The partitions of the test project that run under the scheduling of the operating system are the test partition and the maintenance partition. The test partition only retains the test task and is used to apply stimuli, monitor and send data to the host computer for the test task in the test partition. Step 2: Starting from the entry point of the task under test, work from top to bottom, and instrument each branch in the task under test that may affect the program's direction. The instrumentation information includes the time information of the program running to the instrumentation point. After compilation and linking, the target code of the partition under test is generated. Step 3: Run the target code of the partition under test in the target machine environment. Inject a pre-prepared set of test cases with 100% coverage of the task under test into the task under test in the partition under test through the maintenance partition. Send the time information of each branch collected from all stubs to the host computer for path analysis. The branch coverage of the task under test is the collection result of the task under test from top to bottom. The collection result includes the time information of the first execution of the partition under test, and is repeated at least ten times to eliminate the time randomness caused by a single execution. Step 4: Subtract the execution time of the piling points from the execution time of the task under test to eliminate the error caused by the piling point operation in the task under test; Step 5: By recording the execution time of each branch in the task under test using the piling points, the theoretical worst-case path and the actual worst-case path of the project under test are derived. These two paths are then fitted to the bifurcation points of each branch through supplementary test cases and manual correction, forming a fitted path. Steps 3 to 5 are then repeated on the fitted path to obtain a unique, truly activatable worst-case execution time (WCET) path, and a set of test cases that, after screening, can activate this WCET path. For example... Figure 3 As shown, Figure 2 The illustrated embodiment provides an example diagram of the time analysis and path derivation process in the worst-case execution time path derivation method.

[0028] In one implementation of this invention, the operating system used in the project under test is an embedded real-time operating system that meets the requirements of the ARINC653 specification. This embedded real-time operating system uses partitions as scheduling units, and several processes can run within a partition. The runtime sequence of each partition is configured through a scheduling table. In the project under test, the task under test is configured as a non-real-time task to avoid failures caused by timeouts of real-time tasks, ensuring that the task under test can run normally from the entry point to the exit point. Figure 1 The diagram shown is a schematic of the partition switching timing based on the ARINC653 operating system provided in an embodiment of the present invention.

[0029] It should be noted that in this embodiment of the invention, retaining only the task under test in the partition under test means that the task under test has exclusive access to all time windows in the scheduling table. The reason for this is that after the task under test is executed with stubs, its required execution time needs to span multiple time slices. If the operating system switches to the next partition before the task under test has been completed, it may cause the time for obtaining stubs to be discontinuous, that is, it may span the time of a maintenance partition. Therefore, it is necessary to ensure that each scheduling table has one and only one partition that continues to run until the work tasks in that partition are completely completed.

[0030] Additionally, it should be noted that the execution time of the task under test with piles means that after the piles are inserted to obtain each pile point, the execution time of the task under test should be added to the execution time of each pile point. This is so that when calculating the execution time of the task under test later, the execution time of each pile point can be subtracted from the execution time of the task under test to eliminate the error caused by the operation of the pile points in the task under test.

[0031] In one implementation of this invention, in step 2 above, each branch in the task under test that may affect the program's direction is instrumented at the beginning and end. These branches include, but are not limited to, if / else branches and switch / case branches. For variable-length loops, while and for loops need to be added.

[0032] In one implementation of this invention, in step 3 above, the test cases in the pre-prepared test case set simultaneously satisfy the following conditions: 1) All test cases are designed based on high-level software requirements; 2) The branch coverage of the task to be tested shall be collected from top to bottom, not pieced together from bottom to top. The coverage shall reach or be close to 100%. All branches that cannot be covered shall be manually reviewed or analyzed and have a reasonable explanation. 3) The worst-case execution time path derivation method is to test all branches within the performance verification scope, without needing to guarantee the correctness of the execution function.

[0033] In one implementation of this invention, since the task under test is executed with piles, the time of each pile is recorded by injecting it into the program. The method for eliminating the execution time of the piles in step 4 includes: After running the test at each pile point hundreds of times, the minimum time for each single run is taken. After recording the running time for each branch, the minimum time for each single run at the pile point is subtracted from the running time of the corresponding branch to eliminate the error caused by each pile point.

[0034] It should be noted that the above-mentioned continuous execution of stubs cannot be done in a loop; stubs must be executed continuously to eliminate the impact of cache hit rate on stub execution efficiency.

[0035] In one implementation of this invention, to ensure the minimization of the piling point running time, an efficient way to obtain the piling point program running time is to obtain the time by directly accessing the value of the timer register after frequency division at the underlying level, which can maximize time-saving space. This time is provided by the interface of the ARINC653 operating system.

[0036] In one implementation of this invention, the corresponding handling method for the time fluctuations caused by cache switching, cache hit rate, and processor instruction pipeline factors in the project under test further includes: The execution time of each branch is recorded from the moment the power is turned on. The execution time of branches affected by cache switching, cache hit rate and processor instruction pipeline is recorded in the theoretical worst path. The theoretical worst path records the worst historical execution time of each branch. The affected branches are manually corrected to eliminate the impact of hardware factors.

[0037] It should be noted that in the worst-case execution time path derivation method for the ARINC653 operating system provided in the above embodiments of the present invention, after deriving the theoretical worst-case path and the measured worst-case path in step 5, there are two cases that cause the path to fork, namely: Case 1: The measured worst path does not match the theoretical worst path. By optimizing the test cases that activate the measured worst path, the branch of the theoretical worst path is triggered, that is, the branch point of the measured worst path is fitted to the theoretical worst path. Case 2: The theoretical worst path does not match the measured worst path. There may be multiple reasons for this. In this case, the theoretical worst path is manually corrected. If the branch combination of the theoretical worst path cannot be activated in any scenario, the branch point of the theoretical worst path is fitted to the measured worst path.

[0038] Furthermore, for projects under test that are relatively large in scale, such as those with more than 10,000 lines of code, it is necessary to first slice the project under test, that is, to divide the project under test into parts with low logical coupling, and then perform steps 2 to 5 on each of the resulting sub-projects. After analyzing the worst path of each sub-project, determine whether the worst path of each sub-project can be activated by the same set of test cases. If not, the worst path of each sub-project that can be activated by the same set of test cases is obtained by re-slicing the project under test. If so, the worst paths of each sub-project that can be activated by the same test case set are spliced ​​together to form the WCET path of the project under test.

[0039] This invention proposes a worst-case execution time (WCET) path derivation method for the ARINC653 operating system. It utilizes the ARINC653 standard operating system's partition scheduling and partition isolation mechanisms to isolate the task under test as a non-real-time task on a separate test partition. The task under test is then stimulated, monitored, and data is sent to the host computer. Through measurement, starting from the entry point of the task under test and working downwards, each branch that might affect the program's execution path is instrumented at both the beginning and end to collect the branch times that could potentially influence the program's execution path. This allows for the derivation of the path that might activate the WCET. The beneficial effects of the WCET path derivation method provided by this invention are: First, by utilizing the ARINC653 operating system based on mechanisms such as partition scheduling and partition isolation, the integrity of the task under test is guaranteed to the greatest extent. Second, in this embodiment of the invention, all path selection and analysis processes, as well as time measurement results, are based on the actual measured time of the target machine, so as to obtain the worst execution time WCET path in the most realistic and accurate way, and eliminate the influence of human experience factors on the analysis; compared with the purely static analysis method, the reliability of the time can be guaranteed. Third, for DAL-A, DAL-B, and DAL-C level software, the statement coverage target in DO-178C must be met. This invention combines the statement coverage collection results and goes a step further than the traditional dynamic measurement method of WCET. After obtaining the time execution status of all branches through statistical methods, it analyzes and derives them one by one, and continuously refines test cases that can activate the worst execution path, thereby maximizing the accuracy of the WCET path.

[0040] In summary, this invention provides a method for deriving the worst execution time path based on actual measurements. It is applicable to all projects under test using the ARINC653 operating system framework. By deriving step by step, a set of test cases that can activate the worst execution time is obtained, which maximizes the accuracy of the worst execution time path analysis results.

[0041] The following is a specific embodiment illustrating the implementation of the worst-case execution time path derivation method for the ARINC653 operating system provided by the present invention.

[0042] Please see Figure 2 and Figure 3 The method provided for deriving the worst execution time path for the ARINC653 operating system requires the following preprocessing of the test environment before executing the test task: 1) Clear the partition to be tested and its cache, keeping only the task to be tested, and configure the task to be tested as a non-real-time task to avoid runtime errors caused by the task to be tested needing to run across time slices; 2) Perform instrumentation on each branch in the task under test that may affect the program's execution path, and record the execution time required for each branch; 3) Prepare a set of test cases that are injected from top to bottom, which can achieve 100% statement coverage of the task under test. Write them in the maintenance partition to ensure that the next set is executed after the previous set is completed. 4) Establish a large-capacity data read / write path between the partition under test and the maintenance partition, such as shared memory, message port, or queue port. The space needs to ensure that all stub information of the task under test is filled without overflowing. 5) Instrument all branches of the partition under test to record time, generate the target code of the partition under test and load it into the target machine; 6) For overly complex tasks, task slicing can be performed where the logical coupling is low, i.e., segmented instrumentation analysis of the task.

[0043] Please see Figure 1When testing begins, the first scheduler is run, which is the scheduler that only runs the partition under test. After the tasks have run from top to bottom and all stubs have been filled with the real-time running time, the stub information is shared with the maintenance partition through shared memory, queue ports or message ports. Then the partition under test requests the operating system to switch the scheduler. The operating system responds and switches to the scheduler. The purpose of switching the scheduler is to create an environment in which only the partition under test runs.

[0044] After the scheduler switch, only the maintenance partition runs. The maintenance partition first reads the data shared by the partition under test, and then sends it to the host computer via Ethernet, serial port, or other methods for time data collection. Once the transmission is complete, the maintenance partition injects the next set of test cases to stimulate the partition under test, then clears the shared memory information, switches the scheduler back to the partition under test, and executes the next set of test cases. This process needs to be repeated more than 10 times to avoid the randomness of execution time for each branch.

[0045] After the target machine completes the above steps, the time error caused by the staking information needs to be eliminated. The elimination method is to run the staking function more than 100 times without looping, find the minimum value of the staking in 100 runs, and then subtract the running time of the staking from the time of all branch records to obtain the time information after further elimination processing.

[0046] After the host computer collects all branch stub information, please refer to Figure 3 The host computer can calculate the theoretical worst-case execution time and path, the actual worst-case execution time and path, and their corresponding test cases, as well as the fork points between the two paths, based on the collected time information. Verification personnel can analyze each fork point. When a path fork is found, manual intervention is used to determine whether the path can be additionally activated by adding a test case. If so, the test case is optimized; if not, the theoretical worst-case execution path is optimized. This process is repeated to continuously optimize the test cases corresponding to the two paths and the actual worst-case path, ultimately resulting in a set of test cases that can be activated in a real-world scenario and trigger the worst-case execution path. Finally, this unique test case is run on the target machine, and the execution time of the task under test is measured, thus obtaining the final WCET execution time. It should be noted that... Figure 3 The theoretical worst path is the path obtained by concatenating the historical worst execution times of all branches of the task under test; the actual worst path is the path corresponding to the worst execution time actually triggered by the test case set; the path branching point is the branch where the theoretical worst path and the actual worst path do not match.

[0047] While the embodiments disclosed in this invention are as described above, they are merely illustrative of the embodiments to facilitate understanding of the invention and are not intended to limit the invention. Any person skilled in the art to which this invention pertains may make any modifications and variations in the form and details of the implementation without departing from the spirit and scope disclosed herein; however, the scope of patent protection for this invention shall still be determined by the scope defined in the appended claims.

Claims

1. A method for deriving the worst execution time path for the ARINC653 operating system, characterized in that, The method includes: Step 1: Divide the task to be analyzed into a test project with only two partitions. The partitions of the test project that run under the scheduling of the operating system are the test partition and the maintenance partition. The test partition only retains the test task and is used to apply stimuli, monitor and send data to the host computer for the test task in the test partition. Step 2: Starting from the entry point of the task under test, work from top to bottom, and instrument each branch in the task under test that may affect the program's direction. The instrumentation information includes the time information of the program running to the instrumentation point. After compilation and linking, the target code of the partition under test is generated. Step 3: Run the target code of the partition under test in the target machine environment. Inject a pre-prepared set of test cases with 100% coverage of the task under test into the task under test in the partition under test through the maintenance partition. Send the time information of each branch collected from all stubs to the host computer for path analysis. The branch coverage of the task under test is the collection result of the task under test from top to bottom. The collection result includes the time information of the first execution of the partition under test, and is repeated at least ten times to eliminate the time randomness caused by a single execution. Step 4: Subtract the execution time of the piling points from the execution time of the task under test to eliminate the error caused by the piling point operation in the task under test; Step 5: By recording the execution time of each branch in the task under test through the piling point operation record, the theoretical worst path and the actual worst path of the project under test are derived. The two paths are fitted to the bifurcation points of each branch in the two paths through supplementary test cases and manual correction to form a fitted path. Steps 3 to 5 are repeated on the fitted path to finally obtain a unique, real worst execution time WCET path that can be activated, as well as a set of test cases that can be activated after screening.

2. The method according to claim 1, characterized in that, The operating system used in the project under test is an embedded real-time operating system that meets the requirements of the ARINC653 specification. The embedded real-time operating system uses partitions as the scheduling unit. Several processes can run within a partition. The runtime sequence of each partition is configured in the form of a scheduling table. In the project under test, the task under test is configured as a non-real-time task to avoid failures caused by the timeout of real-time task execution time, and to ensure that the task under test can run normally from the entry point to the exit point.

3. The method according to claim 2, characterized in that, The phrase "the partition under test retains only the task under test" means that the task under test exclusively occupies all time windows in the scheduling table. The reason for this is that after the task under test is executed with stubs, its required execution time spans multiple time slices. If the operating system switches to the next partition before the task under test is completed, it will result in discontinuous acquisition of stub points. Therefore, by exclusively occupying all time windows in the scheduling table for the task under test, it is ensured that there is only one partition under test in the scheduling table that continues to run until the task under test in that partition is completed.

4. The method according to claim 1, characterized in that, In step 2, For each branch in the task under test that may affect the program's direction, instrument the beginning and end of the branch. These branches include, but are not limited to, if / else branches and switch / case branches. For variable-length loops, add while and for loops.

5. The method according to claim 1, characterized in that, In step 3 The pre-prepared test case set contains test cases that simultaneously meet the following conditions: 1) All test cases are designed based on high-level software requirements; 2) The branch coverage of the task to be tested shall be collected from top to bottom, not pieced together from bottom to top. The coverage shall reach or be close to 100%. All branches that cannot be covered shall be manually reviewed or analyzed and have a reasonable explanation. 3) The worst-case execution time path derivation method is to test all branches within the performance verification scope, without needing to guarantee the correctness of the execution function.

6. The method according to claim 1, characterized in that, The task to be tested is executed with staked nodes. The execution time of each staked node is recorded by injecting it into the program. The methods for eliminating the execution time of staked nodes in step 4 include: After running the pile points hundreds of times, the minimum time for a single run is taken. After recording the running time of each branch, the minimum time for a single run of the pile point is subtracted from the running time of the corresponding branch to eliminate the error caused by each pile point. The continuous execution of stubs cannot be done in a loop; stubs must be executed continuously to eliminate the impact of cache hit rate on stub execution efficiency.

7. The method according to claim 6, characterized in that, To minimize the runtime of the stubs, the most efficient way to obtain the program runtime is by directly accessing the value of the timer register after frequency division at the underlying level. This maximizes time-saving space, and the time is provided by the interface of the ARINC653 operating system.

8. The method according to claim 1, characterized in that, The method also includes addressing the time fluctuations caused by cache switching, cache hit rate, and processor instruction pipeline factors in the test project; the method further includes: The execution time of each branch is recorded from the moment the power is turned on. The execution time of branches affected by cache switching, cache hit rate and processor instruction pipeline is recorded in the theoretical worst path. The theoretical worst path records the worst historical execution time of each branch. The affected branches are manually corrected to eliminate the impact of hardware factors.

9. The method according to claim 1, characterized in that, In step 5, after deriving the theoretical worst-case path and the measured worst-case path, there are two cases where the path branches out: Case 1: The measured worst path does not match the theoretical worst path. By optimizing the test cases that activate the measured worst path, the branch of the theoretical worst path is triggered, that is, the branch point of the measured worst path is fitted to the theoretical worst path. Case 2: The theoretical worst path does not match the measured worst path. There may be multiple reasons for this. In this case, the theoretical worst path is manually corrected. If the branch combination of the theoretical worst path cannot be activated in any scenario, the branch point of the theoretical worst path is fitted to the measured worst path.

10. The method according to any one of claims 1 to 9, characterized in that, For a project under test with more than 10,000 lines of code, the project under test is sliced, that is, the project under test is divided into parts with low logical coupling, and steps 2 to 5 are executed on each of the sliced ​​parts. After analyzing the worst path of each sub-project, determine whether the worst path of each sub-project can be activated by the same set of test cases. If not, the worst path of each sub-project that can be activated by the same set of test cases is obtained by re-slicing the project under test. If so, the worst paths of each sub-project that can be activated by the same test case set are spliced ​​together to form the WCET path of the project under test.

Images