WCET estimation method based on model detection

Abstract

The invention relates to the technical field of real-time systems, in particular to a WCET estimation method based on model detection. Comprising the following steps: compiling a C source program into an executable file of a corresponding target architecture; calculating the running time of each basic block in the executable code, and performing static analysis by using a time measurement tool Bound-T; mapping the source code and the corresponding machine code, and marking the running time information of the basic block into the source code; the source code is simplified, and code segments irrelevant to time measurement are trimmed; the CBMC tool is operated, and the WCET of the program is searched; verifying whether the WCET meets the precision requirement of the system, and outputting a result if the WCET meets the precision requirement of the system; otherwise, the analysis option is adjusted, and the CBMC tool is operated again until the WCET meeting the precision requirement is obtained. According to the technical scheme, the efficiency and accuracy of WCET estimation can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of real-time systems, and particularly relates to a WCET estimation method based on model detection. BACKGROUND

[0002] In real-time systems, strict guarantee of response time is the key to system design. Autonomous driving control systems need to respond to external events within a limited time to ensure the safety of the driving process. WCET (Worst-Case Execution Time, i.e. the time required for a program or task to execute in the worst case) analysis is the main means to achieve this goal. Existing WCET estimation methods include integer linear programming (ILP, Integer Linear Programming) and abstract interpretation (AI, Abstract Interpretation), but these methods have limited effect when dealing with complex loops. The model detection method can explicitly explore all paths of program execution, but it has poor scalability in the presence of loops. The TIC method (Ravindra Metta et al. in 2016, document name: "TIC: A Scalable Model Checking Based Approach to WCET Estimation") is a WCET estimation method based on model detection, but its calculation process is complex and involves multiple steps and tools, increasing the difficulty of use and the risk of errors.

[0003] The disadvantages of the prior art include: The TIC method goes through a series of steps when estimating WCET, each step introduces additional calculation and processing overhead, from compilation to slicing, to abstraction and loop acceleration, each step can increase the complexity and time cost of the entire process; During the calculation process, many tools are applied: compilers, time estimation tools, slicing tools, time mapping tools, etc. To get the required WCET, many tools need to be used in combination, which increases the difficulty of use for the user; The accuracy of each step can affect the final WCET estimation result. If there is any error or inaccurate assumption in any step, it will affect the overall accuracy; SUMMARY The purpose of the present application is to provide a WCET estimation method based on model detection, which can improve the efficiency and accuracy of WCET estimation.

[0004] To achieve the above purpose, in a first aspect, the present application provides a WCET estimation method based on model detection, comprising: Compiling the C source program into an executable file of the corresponding target architecture; calculating the running time of each basic block in the executable code using the time measurement tool Bound-T for static analysis; mapping the source code to its corresponding machine code and marking the running time information of the basic blocks into the source code; simplifying the source code and pruning the code segments irrelevant to time measurement; running the CBMC tool to find the WCET of the program; verifying whether the WCET meets the precision requirements of the system, and if so, outputting the result; otherwise, adjusting the analysis options and re-running the CBMC tool until a WCET meeting the precision requirements is obtained.

[0005] The beneficial effects of the basic scheme are: removing the complex processes of program slicing, loop abstraction and acceleration, and avoiding the problem of long process caused by multi-stage processing. In the traditional method, loop abstraction needs to model and simplify the loop structure, while this scheme directly solves it through basic block time calculation and model detection tool (CBMC), reducing the time and computational resource consumption of the intermediate links.

[0006] Simplifying the source code and pruning the code segments irrelevant to time measurement (such as conditional branches of non-critical paths, auxiliary functions), so that the model detection tool (CBMC) only analyzes the critical execution paths. If there are a large number of log records or debugging code in the program, pruning can reduce the state space search range of CBMC and improve the WCET calculation speed.

[0007] Using the Bound-T tool to statically analyze the running time of the basic block, and combining the model detection capability of CBMC to find the WCET of the program. Bound-T can accurately calculate the basic block time based on the characteristics of the target architecture, while CBMC can exhaustively verify all possible execution paths, avoiding the problem that traditional dynamic testing cannot cover all paths, and being more efficient than pure dynamic analysis.

[0008] By removing steps such as program slicing and loop abstraction that require special tool support, the dependence on complex tool chains is reduced. Traditional methods generally require specific program analysis tools for loop abstraction, while this scheme only requires general tools such as Bound-T and CBMC, making it easier to deploy in resource-limited scenarios.

[0009] This technical solution significantly improves the execution efficiency and operability of the method while ensuring the accuracy of WCET estimation, especially suitable for scenarios with high real-time requirements and complex hardware architecture (such as embedded systems and industrial control programs), providing a more efficient and flexible solution for WCET analysis in engineering practice.

[0010] As a preferred embodiment, the C source program is compiled into an executable file of the corresponding target architecture, which includes the following contents: Open Keil development environment and create a new project; Add the C source program to be calculated WCET to the project; Configure the target processor of the project as ARM7TDMI and select the corresponding compiler options; Compile the project to generate the executable file of the target architecture, and observe the compilation output information to ensure that there is no compilation error.

[0011] As an implementable preferred solution, the running time of each basic block in the executable code is calculated, and static analysis is performed using the time measurement tool Bound-T, including the following: Import the executable file into the Bound-T tool; Configure the analysis options, select the target processor architecture as ARM7TDMI, and set the analysis parameters; Run the Bound-T tool to analyze the control flow graph of the executable program and calculate the execution time upper bound of each basic block; Export the analysis results to obtain the running time information of each basic block.

[0012] As an implementable preferred solution, it is characterized by mapping the source code and its corresponding machine code, and marking the running time information of the basic block into the source code, including the following: Open the source code file and prepare for mapping and marking; Determine the corresponding position of each basic block in the source code according to the analysis results; Insert time information annotations at the corresponding source code positions of each basic block; Add an assert(_time < X) type assertion at the entry of the main function to calculate the WCET.

[0013] As an implementable preferred solution, the source code is simplified and the code segments unrelated to time measurement are pruned, including the following: In the process of mapping the binary code basic blocks in the executable program to the source code, the mapping method needs to be selected in combination with the specific code, and the mapping methods used include: One-to-many mapping, inserting the time information of the basic block before the last expression; Many-to-one mapping, converting the loop in the executable program back to the source program, estimating the loop boundary, and estimating the execution time of this segment of program using its worst time value.

[0014] As an implementable preferred solution, the source code is simplified and the code segments unrelated to time measurement are pruned, including the following: Analyze the source code and identify code segments unrelated to time measurement; Removing irrelevant code segments, and keeping the code related to time measurement; Slicing the source code, and reducing the size of the program.

[0015] As an implementable preferred solution, a CBMC tool is run to find the WCET of the program, including the following steps: Importing the simplified source code into the CBMC tool; Configuring analysis options, and setting the required precision; Running the CBMC tool to analyze the control flow graph of the program, find the longest execution path of the program, and calculate the WCET of the program; Exporting the analysis results to obtain the WCET of the program.

[0016] As an implementable preferred solution, the CBMC tool analyzes the control flow graph of the program by model detection, finds the longest execution path of the program, and calculates the WCET of the program. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 A flowchart of a WCET estimation method based on model detection provided by an embodiment of the present application.

[0018] Figure 2 A schematic diagram of the architecture of an electronic device provided by an embodiment of the present application.

[0019] The electronic device 500, the processor 501, the communication interface 502, the memory 503, and the bus 504. DETAILED DESCRIPTION

[0020] In order to make the technical solutions of the present application and their advantages clearer, the technical solutions of the present application will be further described in detail below with reference to the accompanying drawings. It can be understood that the specific embodiments described herein are only partial embodiments of the present application, and are only used to explain the present application, but not to limit the present application. It should be noted that the technical features or combinations of technical features described in the following embodiments should not be considered in isolation, and they can be combined with each other to achieve better technical effects. The same reference numerals appearing in the accompanying drawings of the following embodiments represent the same features or components, which can be applied to different embodiments.

[0021] In addition, unless otherwise defined, the technical terms or scientific terms used in the description of the present application should have the usual meanings understood by those of ordinary skill in the art to which the present application belongs.

[0022] The present application will be further described in detail below with reference to the accompanying drawings: With reference to Figure 1 The WCET estimation method based on model detection comprises the following steps: Step S100, the C source program is compiled into the corresponding target architecture executable file. In this embodiment, the Keil is used to compile the input program, the target processor is ARM7TDMI, and the corresponding chip is NXP LPC2138. The specific steps are as follows: Step S101, open the Keil development environment, create a new project, and name it "WCET_Estimation".

[0023] Step S102, add the C source program "example.c" to be calculated WCET to the project.

[0024] Step S103, configure the target processor of the project as ARM7TDMI, and select the corresponding compiler options, including optimization level, debugging information, etc. Step S104, compile the project to generate the executable file "example.axf" of the target architecture. During the compilation process, attention should be paid to observe the compilation output information to ensure that there is no compilation error. If there is an error, the problem in the C source program should be checked and corrected in time, and then recompiled.

[0025] Step S200: Calculate the running time of each basic block in the executable code, and use the time measurement tool Bound-T to calculate the running time of each basic block in the executable code. Bound-T is a static analysis tool that can calculate the upper bound of the running time of the executable program through static analysis. The specific steps are as follows: Step S201, open the Bound-T tool (a time analysis tool for embedded systems, used to estimate the maximum execution time upper bound of each basic block in the program. Bound-T tool can derive the execution time upper bound of the program through static analysis without running the program itself), import the executable file "example.axf" generated by the previous step of compilation.

[0026] Step S202, configure the analysis options of the Bound-T tool, select the target processor architecture as ARM7TDMI, and set the analysis parameters such as clock frequency, memory model, etc.

[0027] Step S203, run the Bound-T tool to perform static analysis and calculate the running time of each basic block. The Bound-T tool analyzes the control flow graph of the executable program through static analysis to calculate the execution time upper bound of each basic block.

[0028] Step S204, export the analysis results to obtain the running time information of each basic block and save it as a "example_timing.txt" file.

[0029] Step S300, map the source code to its corresponding machine code and mark the runtime information of basic blocks in the source code, the specific steps are as follows: Step S301, open the source code file "example.c" and prepare for mapping and marking.

[0030] Step S302, according to the analysis result "example_timing.txt" of Bound-T tool, determine the corresponding position of each basic block in the source code, for example, basic block 1 corresponds to the function "function1" in the source code, basic block 2 corresponds to the function "function2", etc.

[0031] Step S303, add the runtime information of basic blocks to the source code, specifically, insert time information comments at the corresponding source code position of each basic block.

[0032] Step S304, add an assertion in the form of assert(_time<X) at the entrance of the main function to calculate the WCET.

[0033] In the process of mapping the binary code basic blocks in the executable program to the source code, due to the difference in control flow structure, the mapping process is not easy and needs to be considered in combination with specific code. The mapping methods used at present are mainly divided into two categories: One-to-many mapping: one basic block in the executable program corresponds to one or more consecutive expressions in the source code. At this time, the time information of the basic block needs to be inserted before the last expression.

[0034] Many-to-one mapping: source expressions are split into different control paths in binary. Several basic blocks in the executable program may need to be mapped to a single source expression. In this case, the loop in the executable program needs to be converted back to the source program, the loop boundary is estimated, and the worst time value of the loop is used to estimate the execution time of the program.

[0035] Step S400, simplify the source code. When calculating the WCET, the upper bound of the target program running time is concerned, and the program running time related information has been added to the source code in the last step. Therefore, the source code can be simplified in this step, and some code that actually performs actions is pruned, and some calculation overheads unrelated to time measurement are eliminated. The specific steps are as follows: Step S401, analyze the source code and identify code segments unrelated to time measurement. For example, debugging information output, log recording and other code segments in the source code are unrelated to time measurement and can be removed.

[0036] Step S402, remove irrelevant code segments, and keep the code related to time measurement. For example, remove the call of the debug information output function "debug_print()", and keep the function call related to time measurement.

[0037] Step S403, slice the source code, reduce the size of the program, and further reduce the running time of the program. For example, remove the function call and variable definition irrelevant to time measurement, and keep the function call and variable definition related to time measurement.

[0038] Step S500, run CBMC (Cryptographic Boolean Functions Manipulation and Compilation, a tool for formal verification), find the WCET of the program, combine the Python script implemented in the TIC technology, set the required precision, run CBMC with the source program as input, and finally get the upper bound of the running time of the input program, i.e. the WCET that meets the precision requirement. The specific steps are as follows: Step S501, open the CBMC tool and import the simplified source code "example_simplified.c" in the previous step.

[0039] Step S502, configure the analysis options of the CBMC tool and set the required precision.

[0040] Step S503, run the CBMC tool to perform model checking and find the WCET of the program. The CBMC tool analyzes the control flow graph of the program through model checking, finds the longest execution path of the program, and calculates the WCET of the program.

[0041] Step S504, export the analysis results and obtain the WCET of the program.

[0042] Step S600, get the WCET that meets the precision requirement. After a series of processing steps, the upper bound of the running time of the input program is finally obtained, i.e. the WCET that meets the precision requirement. The specific steps are as follows: Step S601, analyze the analysis results of the CBMC tool and confirm the WCET of the program.

[0043] Step S602, verify whether the WCET meets the precision requirement of the system.

[0044] Step S603, if the WCET meets the precision requirement, output the result; otherwise, adjust the analysis options and run the CBMC tool again until the WCET that meets the precision requirement is obtained.

[0045] The embodiment of the present application further provides an electronic device 500, which applies the WCET estimation method based on model detection, and comprises a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and the processor implements the steps of the WCET estimation method based on model detection when executing the program. In the embodiment of the present application, the processor is the control center of the computer method, and can be a processor of a physical machine or a processor of a virtual machine.

[0046] With reference to Figure 2 The electronic device 500 comprises at least one processor 501, at least one communication interface 502, at least one memory 503, and at least one bus 504. The bus 504 is used to realize the connection communication among the components, the communication interface 502 is used to communicate with other node devices, and the memory 503 stores machine readable instructions executable by the processor 501. When the electronic device 500 is running, the processor 501 communicates with the memory 503 through the bus 504, and the machine readable instructions are executed by the processor 501 to implement the steps of the WCET estimation method based on model detection.

[0047] The present application further provides a computer readable storage medium, which stores a computer program, and the computer program can implement the steps of the WCET estimation method based on model detection when executed by the processor of the electronic device.

[0048] Those of ordinary skill in the art can understand that all or part of the flow of the WCET estimation method based on model detection can be implemented by a computer program instructing relevant hardware. The program can be stored in a non-volatile computer readable storage medium, and when the program is executed, the flow of each embodiment of the WCET estimation method based on model detection can be included. Any reference to memory, storage, database or other medium used in each embodiment provided by the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0049] The above is only an embodiment of the present application, and the common knowledge of specific structures and characteristics in the scheme is not described in detail. Those of ordinary skill in the art know all the ordinary technical knowledge in the field of the present application before the filing date or the priority date, can know all the prior art in the field, and have the ability to apply conventional experimental means before that date. Those of ordinary skill in the art can improve and implement the present scheme based on their own ability under the guidance of the present application, and some typical known structures or known methods should not be an obstacle for those of ordinary skill in the art to implement the present application. It should be noted that those of ordinary skill in the art can make several modifications and improvements without departing from the structure of the present application, which should be considered as the protection scope of the present application, and these will not affect the effect and practicality of the present application. The protection scope of the present application should be subject to the content of its claims, and the specific implementation mode in the specification can be used to explain the content of the claims.

Claims

1. A WCET estimation method based on model checking, characterized in that: including: Compile the C source program into an executable file for the corresponding target architecture; Calculate the running time of each basic block in the executable code, and perform static analysis using the time measurement tool Bound-T; map the source code to its corresponding machine code, and mark the running time information of the basic blocks in the source code; simplify the source code and trim the code segments irrelevant to time measurement; run the CBMC tool to find the WCET of the program; verify whether the WCET meets the accuracy requirements of the system, and if so, output the result; Otherwise, adjust the analysis options and re-run the CBMC tool until a WCET that meets the accuracy requirements is obtained.

2. The WCET estimation method based on model checking according to claim 1, characterized in that: Compiling the C source program into an executable file for the corresponding target architecture includes the following: Open the Keil development environment and create a new project; Add the C source program for which the WCET is to be calculated to the project; Configure the target processor of the project as ARM7TDMI and select the corresponding compiler options; Compile the project to generate an executable file for the target architecture, and observe the compilation output information to ensure there are no compilation errors.

3. The WCET estimation method based on model checking according to claim 1, characterized in that: Calculating the running time of each basic block in the executable code and performing static analysis using the time measurement tool Bound-T includes the following: Import the executable file into the Bound-T tool; Configure the analysis options, select the target processor architecture as ARM7TDMI, and set the analysis parameters; Run the Bound-T tool to analyze the control flow graph of the executable program and calculate the upper bound of the execution time of each basic block; Export the analysis results to obtain the running time information of each basic block.

4. The WCET estimation method based on model checking according to claim 3, characterized in that: Mapping the source code to its corresponding machine code and marking the running time information of the basic blocks in the source code includes the following: Open the source code file to prepare for mapping and marking; Determine the corresponding position of each basic block in the source code according to the analysis results; Insert time information comments at the corresponding source code positions of each basic block; Add an assertion in the form of assert(_time<X) at the entry of the main function to calculate the WCET.

5. The WCET estimation method based on model checking according to claim 1, characterized in that: Simplifying the source code and trimming the code segments irrelevant to time measurement includes the following: In the process of mapping the binary code basic blocks in the executable program to the source code, the mapping method needs to be selected according to the specific code. The mapping methods used include: One-to-many mapping, insert the time information of the basic block before the last expression; Many-to-one mapping, convert the loop in the executable program back to the source program, estimate the loop boundary, and use its worst time value to estimate the execution time of this section of the program.

6. The WCET estimation method based on model checking according to claim 1, characterized in that: Simplifying the source code and trimming the code segments irrelevant to time measurement includes the following: Analyze the source code to identify the code segments irrelevant to time measurement; Remove the irrelevant code segments and retain the code related to time measurement; Slice the source code to reduce the program scale.

7. The WCET estimation method based on model checking according to claim 1, characterized in that: Running the CBMC tool to find the WCET of the program includes the following: Import the simplified source code into the CBMC tool; Configure the analysis options and set the required accuracy; Run the CBMC tool to analyze the control flow graph of the program, find the longest execution path of the program, and calculate the WCET of the program; Export the analysis results and obtain the WCET of the program.

8. The WCET estimation method based on model checking according to claim 7, characterized in that: The CBMC tool uses model checking to analyze the control flow graph of the program, find the longest execution path of the program, and calculate the WCET of the program.

Images