Method for analyzing worst running time of embedded software

Abstract

The invention belongs to the technical field of software verification. The invention provides a worst runtime analysis method for embedded software. The method comprises the following steps: traversing all functions of software to obtain all effective paths; analyzing all execution branches and execution time of the function to obtain branch execution time of all function branches; dividing the function into a simple function and a complex function according to the branch execution time; based on the effective path, the simple function and the complex function, optimally selecting a worst running time path sequence of the test; and designing a plurality of corresponding test cases according to the worst running time path sequence, inserting test points in software, and executing each test case to obtain the worst running time. According to the embodiment of the invention, paths with shorter time can be effectively eliminated, and possible paths with worst running time can be found out more quickly; and meanwhile, the design of the test case is optimized, and the effective worst running time is obtained based on the test.

Description

Technical Field

[0001] The disclosed embodiments relate to the technical field of software verification, and in particular to a worst-case runtime analysis method for embedded software. Background Art

[0002] With the rapid development of computer technology, embedded software has played an important role in more and more important fields such as automobiles, aerospace, aviation, and ships. The level of embedded software development is also directly related to the quality of the product, which not only affects people's lives, but also affects people's life and property safety. Therefore, embedded software verification plays an important role. Worst-case runtime analysis is an important part of software verification and an important means to analyze the resource usage of embedded systems, which is of great help in optimizing software design.

[0003] "Software Considerations in Airborne Systems and Equipment Certification" (DO-178B for short) sets requirements for tasks at each stage of software development, among which worst-case runtime analysis is an essential activity in the software verification process.

[0004] Traditional software worst-case runtime methods are generally based on static analysis or dynamic analysis.

[0005] The general method of static analysis is to first analyze the resources and performance of the processor used to obtain the time of each assembly instruction of the software; then analyze and obtain the assembly instruction set of each path of the software; finally, based on the time of each instruction, calculate the total execution time of each path, and select the worst runtime path and the worst runtime. The advantage of this method is that once the time of each instruction is analyzed, it is easy to obtain the time of each path of the software and the worst runtime. However, the disadvantage is that the time analysis of assembly instructions is a very complicated process, so it takes a lot of time, or it is difficult to obtain the accurate instruction execution time, which ultimately leads to a large error in the worst runtime obtained.

[0006] The general method of dynamic analysis is to first analyze all possible execution paths of the software, then design test cases based on each possible path, and finally insert test points in the software. After executing the test cases, the execution time of each path is obtained, and the worst running time path and the worst running time are selected. The advantage of this method is that the time of each path can be obtained more accurately through testing. However, the problem is that the process of designing test cases for all paths is very complicated, especially for software with very complex structures, which leads to incomplete design of test cases, or a lot of time is spent on designing test cases, and effective analysis results cannot be obtained.

[0007] The above methods all have the problems of complex operation, great difficulty and time-consuming.

[0008] Therefore, it is necessary to improve one or more problems existing in the above-mentioned related technical solutions.

[0009] It should be noted that this section is intended to provide background or context for the technical solutions of the present disclosure stated in the claims. The description herein is not admitted to be prior art by virtue of being included in this section. Summary of the invention

[0010] In order to avoid the deficiencies of the prior art, the present application provides a worst-case runtime analysis method for embedded software, which is used to solve the problems of complex operation, high difficulty and time-consuming in the prior art.

[0011] According to an embodiment of the present disclosure, a worst-case runtime analysis method for embedded software is provided, the method comprising: Traverse all functions of the software to obtain all valid paths; For each of the functions, analyzing all execution branches of the function and their execution times to obtain branch execution times of all the function branches; According to the branch execution time, the function is divided into a simple function and a complex function; Based on the valid path, the simple function and the complex function, optimizing and selecting the worst runtime path sequence for testing; According to the worst running time path sequence, several corresponding test cases are designed, test points are inserted into the software, and each of the test cases is executed to obtain the worst running time.

[0012] Furthermore, the steps of traversing all functions of the software to obtain all valid paths include: Starting from the main function of the software, the calling relationships of all the functions are analyzed layer by layer, and the function calling tree is gradually obtained; Analyze each branch of the function based on the function call tree to obtain a branch call tree with branch information; Traversing the branch call tree to obtain all execution paths; The judgment criteria of each branch are analyzed, and based on the mutual coupling relationship between different branches, the unreachable branches in the execution path are eliminated to obtain all the valid paths.

[0013] Furthermore, for each of the functions, analyzing all execution branches of the function and their execution times to obtain the branch execution times of all the function branches includes: For each of the functions, the function execution flow is analyzed, and a statement execution diagram of the function is obtained based on the branches, so as to sort out the execution status of the statements of all function branches; evaluating the execution of the statement to obtain the relative time of the statement; The execution time of each path is calculated according to the relative time and function structure of the statement to obtain the branch execution time of all the function branches.

[0014] Furthermore, the step of dividing the function into simple functions and complex functions according to the branch execution time includes: Classify the function whose branch execution time is greater than or equal to a preset value into the simple function; The function whose branch execution time is less than the preset value is classified as the complex function.

[0015] Further, the step of optimizing and selecting the worst runtime path sequence for testing based on the valid path, the simple function and the complex function includes: Listing all the function branches corresponding to the complex function into the worst runtime path sequence; The function branches with the longest execution time in the simple functions are listed in the worst runtime path sequence.

[0016] Furthermore, if there are multiple function branches in the simple function whose execution time is the longest, any one of the function branches is selected to be included in the worst runtime path sequence.

[0017] Furthermore, the step of designing a plurality of corresponding test cases according to the worst running time path sequence, inserting test points in the software, and executing each of the test cases to obtain the worst running time includes: Designing a number of corresponding test cases according to the worst running time path sequence; A test point is inserted into the software, the execution time of the software is counted, and all the test cases are executed to compare the execution time of all the test cases, and the one with the longest execution time is selected as the worst running time.

[0018] The technical solution provided by the embodiments of the present disclosure may have the following beneficial effects: In the embodiment of the present disclosure, through the worst-case running time analysis method of the above-mentioned embedded software, on the one hand, a method for dividing functions into "simple functions" and "complex functions" is proposed. And based on the division of functions, a method for optimizing the worst-case running time path of functions is proposed. This method can effectively exclude paths with smaller time and find possible paths of the worst-case running time more quickly; at the same time, it optimizes the test case design and obtains an effective worst-case running time based on the test. On the other hand, it combines the advantages of static analysis and dynamic testing, and simplifies the analysis process and the design process of test cases. When analyzing the function branch time, it only needs to find the relative time and analyze the maximum time path, which simplifies the analysis method; when designing the test case, the path of the "simple function" is optimized, which narrows the analysis scope and simplifies the test case design. Using this method, the analysis efficiency of the worst-case running time can be effectively improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification are used to explain the principles of the present disclosure. Obviously, the accompanying drawings described below are only some embodiments of the present disclosure, and for ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without creative work.

[0020] Figure 1 A step diagram showing a worst-case runtime analysis method for embedded software in an exemplary embodiment of the present disclosure; Figure 2 A specific flow chart showing a worst-case runtime analysis method for embedded software in an exemplary embodiment of the present disclosure; Figure 3 A software branch call tree diagram in an exemplary embodiment of the present disclosure is shown; Figure 4 The diagram shows function branches and branch timing in an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0021] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that the disclosure will be more comprehensive and complete and to fully convey the concepts of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0022] In addition, the accompanying drawings are only schematic illustrations of the embodiments of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the figures represent the same or similar parts, and their repeated descriptions will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities.

[0023] This example implementation provides a worst-case runtime analysis method for embedded software. Figure 1 As shown in , the worst-case running time analysis method for embedded software may include: steps S101 to S105.

[0024] Step S101: traverse all functions of the software to obtain all valid paths; Step S102: for each of the functions, analyzing all execution branches of the function and their execution time to obtain branch execution time of all the function branches; Step S103: dividing the function into simple functions and complex functions according to the branch execution time; Step S104: Optimizing and selecting the worst runtime path sequence for testing based on the valid path, the simple function and the complex function; Step S105: designing a number of corresponding test cases according to the worst running time path sequence, inserting test points into the software, and executing each of the test cases to obtain the worst running time.

[0025] Through the above-mentioned worst-case running time analysis method of embedded software, on the one hand, a method for dividing functions into "simple functions" and "complex functions" is proposed. Based on the division of functions, a method for optimizing the worst-case running time path of functions is proposed. This method can effectively exclude paths with smaller time and find possible paths of the worst-case running time more quickly; at the same time, it optimizes the test case design and obtains effective worst-case running time based on the test. On the other hand, it combines the advantages of static analysis and dynamic testing, and simplifies the analysis process and the test case design process. When analyzing the function branch time, it only needs to find the relative time and analyze the maximum time path, which simplifies the analysis method; when designing the test case, the path of the "simple function" is optimized, which narrows the analysis scope and simplifies the test case design. Using this method, the analysis efficiency of the worst-case running time can be effectively improved.

[0026] Next, we will refer to Figures 1 to 4 Each step of the worst-case runtime analysis method for embedded software in this example implementation is described in more detail.

[0027] In step S101, the function call relationship is analyzed layer by layer starting from the main function, and the function call tree is gradually obtained; then the branches of each function are analyzed to obtain a branch call tree with branch information; the branch call tree is traversed to obtain all possible execution paths; according to the software execution logic, unreachable branches are excluded to obtain a valid path.

[0028] In step S102, according to the judgment statements of each branch of the function, all the execution branches of the function are found, and the statements or instructions of each execution branch are listed. The relative execution time of each statement or instruction is evaluated, and then the relative execution time of each branch is calculated. It is not necessary to calculate the exact execution time of each statement or instruction based on the processor, but only to obtain the relative time based on information such as statement complexity and number of loops.

[0029] In step S103, based on the execution time of each function branch in step S102 and according to the software level, a "critical value" of time is determined. If the maximum execution branch time of the function is less than this value, the function is defined as a "simple function" and the remaining functions are "complex functions".

[0030] In step S104, all valid paths obtained in step S101 are analyzed to determine whether the function on each path is a "simple function" or a "complex function". For a "complex function", all paths of the function are listed as the worst runtime path sequence; for a "simple function", only one path is selected as the worst runtime path, where if the execution time of each branch is close, any branch is selected, otherwise the maximum time branch is selected. Finally, the worst runtime path sequence is formed, which excludes some paths with shorter execution time and forms a path set that needs to be tested.

[0031] In step S105, test cases are designed based on the worst runtime path sequence of step S104, and test points are inserted into the software to count the execution time of the software. Then, after executing the test cases, the execution time of each path is compared to obtain the worst runtime time.

[0032] In a specific embodiment, Figure 2 As shown, the present application provides a method for analyzing the worst-case running time of embedded software, the method comprising the following steps: Step S101: Find all valid execution paths of the software. The specific implementation method is: (1) Start from the main function and analyze layer by layer to find out the calling relationship of each level of function, and finally obtain the function call tree that describes the function calling relationship; (2) Analyze the branch statements (if...else..., switch...case..., etc.) within each function to obtain the analysis information of the function; (3) Integrate the function branch information and function call relationship to obtain a software branch call tree containing branch information, such as Figure 3 As shown; (4) Traverse the branch call tree to obtain all possible execution paths of the software; (5) Analyze the judgment criteria of each branch, consider the mutual coupling relationship between different branches, eliminate unreachable branches, and obtain an effective execution path.

[0033] Step S102: Analyze each function branch and the execution time of each branch. The specific implementation method is: (1) Analyze the function execution process and draw the statement execution diagram of the function based on the branches. Figure 4 As shown in the figure, the statement block is a group of statements executed sequentially, which can be conditional judgment statements, assignment and calculation statements, separate loop statements, function call statements, etc. Based on the block diagram, the statement execution status of each branch of the function is sorted out.

[0034] (2) The time of the basic statement is set as a unit time, and the execution time of the remaining statements is calculated based on the statement complexity, loop test, etc. The function call statement only calculates the time of the call statement. Finally, the time of each statement is obtained.

[0035] (3) Based on the time of each statement and the function structure, calculate the execution time of each path. If the function contains a loop structure, calculate it based on the number of loop tests of the statement block.

[0036] Step S103: Divide into "simple functions" and "complex functions". The specific implementation method is: in actual engineering, fully consider the complexity of the software, the resources allocated to the software, the worst running time margin and other information to determine the "critical value" of the division. Based on the analysis result of step S102, if the maximum branch time of the function is greater than the "critical value", it is determined to be a "complex function", otherwise it is a "simple function". If in the analysis process of step S102, it can be determined that the branch time of the function is greater than the "critical value", the subsequent analysis can be omitted and it can be directly determined as a "complex function".

[0037] Step S104: Optimize and select the worst-case runtime path sequence. The specific implementation method is: based on the analysis results of step S101, optimize the path by the function type on each path. For the "complex function" on the path, all its branches are included in the worst-case runtime path sequence and considered in the test case design of step S105; for the "simple function" on the path, only one of its branches needs to be considered. If the time of all branches of the function is basically the same, any branch can be selected, otherwise, the branch with the longest runtime is selected. Through the above optimization method, paths with smaller runtimes are excluded to obtain the worst-case runtime path sequence.

[0038] Step S105: Insert test points, design and execute test cases covering all paths in step S104, and obtain the worst running time. The specific implementation method is: output the cycle execution time of the software by designing functions or inserting discrete outputs, etc., for statistical calculation of the worst running time. Based on the analysis results of step S104, design test cases and execute the test cases. Output the time of each path through the test points, and compare to obtain the worst running time of the software.

[0039] Taking a certain airborne software as an example, part of the code of the main function of the software is as follows: int main(void) { … if(Type != 0) { SetStat(); } else { } ReceiveMessages(); … } According to step S101, the main function can be divided into two branches, namely branch 1 and branch 2. The function SetStat can be identified as Figure 3 Function F1 in the function is analyzed, and part of its code is as follows: void SetStat(void) { … if(nvFlag == 0) { PLLCON = 3; PLLCFG = 0x23; PLLFEED = 0x55; MAMTIM = 3; MAMCR = 2; } else { PLLCON = 0; } … } It can be seen that the function has two branches, called branch 3 and branch 4, which can be corresponding to Figure 3There are two branches in F1. That is, starting from the main function, four execution paths can be obtained. And so on, all execution paths of the software can be obtained.

[0040] According to step S102, the execution time of a statement is defined as 1. In the main function, the execution time of the function call statement in if is 1, and in else is 0. In the SetStat function, the execution time of the statement in if is 5, and in else is 1. Therefore, starting from the main function, the execution time of each path is 6, 2, 5, and 1. It can be seen that the path from branch 1 to branch 3 is the longest path.

[0041] According to step S103, the number and complexity of the ReceiveMessages function involved in the software are much greater than that of the SetStat function. If 70% of the maximum running time of the function is taken as the critical value, SetStat can be divided into a simple function and ReceiveMessages can be divided into a complex function.

[0042] According to step S104, ReceiveMessages is a complex function, and all branches of the function do not need to be optimized. SetStat is a simple function. Through the analysis of step S102, the execution time from branch 1 to branch 3 is the longest, so only test cases need to be designed for this path.

[0043] According to step S105, discrete pulse signals are inserted at the beginning and end of the main function respectively. The test case is executed by testing the interval of the pulse signal through an oscilloscope to obtain the execution time of the software under the path, and finally the worst running time can be obtained.

[0044] The above description is only a preferred implementation mode of the present application and is not intended to limit the scope of implementation of the present application. Any equivalent changes and modifications made within the protection scope of the present application should be deemed to fall within the protection scope of the present application.

[0045] Through the above-mentioned worst-case running time analysis method of embedded software, on the one hand, a method for dividing functions into "simple functions" and "complex functions" is proposed. Based on the division of functions, a method for optimizing the worst-case running time path of functions is proposed. This method can effectively exclude paths with smaller time and find possible paths of the worst-case running time more quickly; at the same time, it optimizes the test case design and obtains effective worst-case running time based on the test. On the other hand, it combines the advantages of static analysis and dynamic testing, and simplifies the analysis process and the test case design process. When analyzing the function branch time, it only needs to find the relative time and analyze the maximum time path, which simplifies the analysis method; when designing the test case, the path of the "simple function" is optimized, which narrows the analysis scope and simplifies the test case design. Using this method, the analysis efficiency of the worst-case running time can be effectively improved.

[0046] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of the present disclosure, the meaning of "multiple" is two or more, unless otherwise clearly and specifically defined.

[0047] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present disclosure. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification.

[0048] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any modification, use or adaptation of the present disclosure, which follows the general principles of the present disclosure and includes common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present disclosure are indicated by the appended claims.

Claims

1. A worst-case runtime analysis method for embedded software, characterized in that: The method includes: Traverse all functions of the software to obtain all valid paths; For each of the functions, analyzing all execution branches of the function and their execution times to obtain branch execution times of all the function branches; According to the branch execution time, the function is divided into a simple function and a complex function; Based on the valid path, the simple function and the complex function, optimizing and selecting the worst runtime path sequence for testing; According to the worst running time path sequence, several corresponding test cases are designed, test points are inserted into the software, and each of the test cases is executed to obtain the worst running time.

2. The worst-case runtime analysis method for embedded software according to claim 1, characterized in that: The steps of traversing all functions of the software to obtain all valid paths include: Starting from the main function of the software, the calling relationships of all the functions are analyzed layer by layer, and the function calling tree is gradually obtained; Analyze each branch of the function based on the function call tree to obtain a branch call tree with branch information; Traversing the branch call tree to obtain all execution paths; The judgment criteria of each branch are analyzed, and based on the mutual coupling relationship between different branches, the unreachable branches in the execution path are eliminated to obtain all the valid paths.

3. The worst-case runtime analysis method for embedded software according to claim 2, characterized in that: For each of the functions, the step of analyzing all execution branches of the function and their execution time to obtain the branch execution time of all the function branches includes: For each of the functions, the function execution flow is analyzed, and a statement execution diagram of the function is obtained based on the branches, so as to sort out the execution status of the statements of all function branches; evaluating the execution of the statement to obtain the relative time of the statement; The execution time of each path is calculated according to the relative time and function structure of the statement to obtain the branch execution time of all the function branches.

4. The worst-case runtime analysis method for embedded software according to claim 3, characterized in that: The step of dividing the function into a simple function and a complex function according to the branch execution time includes: Classify the function whose branch execution time is greater than or equal to a preset value into the simple function; The function whose branch execution time is less than the preset value is classified as the complex function.

5. The worst-case runtime analysis method for embedded software according to claim 4, characterized in that: The step of optimizing and selecting the worst runtime path sequence for testing based on the valid path, the simple function and the complex function comprises: Listing all the function branches corresponding to the complex function into the worst runtime path sequence; The function branches with the longest execution time in the simple functions are listed in the worst runtime path sequence.

6. The worst-case runtime analysis method for embedded software according to claim 5, characterized in that: If there are multiple function branches in the simple function whose execution time is the longest, then any one of the function branches is selected to be included in the worst runtime path sequence.

7. The worst-case runtime analysis method for embedded software according to claim 5, characterized in that: The step of designing a plurality of corresponding test cases according to the worst running time path sequence, inserting test points in the software, and executing each of the test cases to obtain the worst running time includes: Designing a number of corresponding test cases according to the worst running time path sequence; A test point is inserted into the software, the execution time of the software is counted, and all the test cases are executed to compare the execution time of all the test cases, and the one with the longest execution time is selected as the worst running time.

Images